<*>[Attachment(s) from Wouter Simons included below]
I am reading this thread with a little bit of amusement. The original
question has been answered I believe, so perhaps a new thread should be
started on why one would choose to do kernel space development vs. user
space development.
AFAIK, the most important reason to choose kernel space programming is
because you want to be able to use the processor in system mode. System
mode makes it possible to handle interrupts (FIQ/IRQ) among other
things. Another valid reason might be to create a nicely modular design,
where your main application can remain as is when you substitute one
driver module for another.
Arguably, using mmap from userspace forces you to run your application
as root, but I am not sure how much of an issue this is on an embedded
application, where you have complete control over all running processes.
At the same time, developing kernel space modules requires a lot more
thinking about concurrency and reentrancy (especially now with
preemption in the kernel) of your application making it more difficult
to design.
I can see how the TS-7000 series is aimed at easily developing an
embedded system based on technologies many developers are already
familiar with. In this scenario, where one might only want to do some
simple IO operations, I think peekpoke can work fine.
At the same time, the TS-7000 series also offers a powerful and
thoroughly tested hardware platform that you can customize to fit your
needs exactly. If you are truly worried about performance requirements,
there is nothing stopping you from writing your own pre-emptive
scheduler to replace the OS.
The latest Linux kernels offer many features once only available in
RTOS's such as preemption and high resolution timers. If you write a
kernel driver you can access all this functionality and much more, but I
would never recommend that approach to a novice user unless absolutely
needed.
Wouter
On Sat, 2010-07-31 at 13:51 +0100, Breton M. Saunders wrote:
>
> Russ,
>
> Look - we're going to clearly disagree on this. Back in the 8 bit
> days bit banging was acceptable. Things have moved on since then.
> I'll
> leave the arguments at this point since we're just wasting mailing
> list
> bandwidth.
>
> Can you please explain to me how you would do anything reliable with
> the SYSCON block in the ep93xx from user mode code?
>
> As far as security is concerned, can you please explain why on any
> unix box one might find processed running as say "daemon", "syslog",
> "mysql", "postfix", etc....?
>
> Ring fenced design. Ring fenced, like FUSE - good idea. Using
> /dev/mem isn't ring fenced. Unless you run two user mode programs,
> one
> as root using /dev/mem, the other as the application communicating
> over
> a socket the security model is inherently broken.
>
> -Brett
>
> On 30/07/10 17:42, Russ Nelson wrote:
> > On Fri, 2010-07-30 at 15:48 +0100, Breton M. Saunders wrote:
> >
> >> On 07/30/2010 02:36 PM, Russell N. Nelson - rnnelson wrote:
> >>
> >>> Urgh. Pretty sure you don't know what you're talking about, but
> I'll not
> >>> write you off if you explain your logic.
> >>>
> >>>
> >> Ha. Makes me smile.
> >>
> >> On a OSless machine peek and poke are the expected norm for i/o.
> >>
> >> On linux one writes a driver:
> >> * For performance guarantees
> >>
> > The kernel is interruptible. No guarantee of real-time performance.
> >
> >
> >> * Interrupt usage
> >>
> > True, but either 1) nothing is handling the interrupt at the moment
> in
> > which case you NEED a driver anyway, or 2) something is already
> handling
> > the interrupt, in which case you have to access the device through
> the
> > kernel API. This issue doesn't inform your choice of user-mode
> versus
> > kernel-mode -- it drives it.
> >
> >
> >> * Security
> >>
> > No, no, that's my argument point. Kernel drivers always run as root,
> > whereas a user-mode program can be granted only the privileges it
> needs
> > to run. Kernel drivers == less security.
> >
> >
> >> * Encapsulation of functionality
> >>
> > A user-mode program gets you exactly the same encapsulation. A
> > kernel-mode driver
> >
> >
> >> All peekpoke is doing is creating a lot of unreliable applications
> out
> >> there. I wouldn't ship a solution to a customer using that approach
> -
> >> network attached or not.
> >>
> > Why are the applications unreliable? You're making claims that
> aren't
> > supported by the facts. The init program will never die as long as
> the
> > kernel is running. It will restart programs that exit if they're
> listed
> > in /etc/inittab. So even if your application crashes, the kernel,
> > through init, will restart it.
> >
> > If, on the other hand, your kernel driver crashes, the entire
> operating
> > system goes down with it. I don't see how a kernel mode driver is
> > necessarily more reliable.
<*>Attachment(s) from Wouter Simons:
<*> 1 of 1 File(s)
http://groups.yahoo.com/group/ts-7000/attachments/folder/713379908/item/list
<*> winmail.dat
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|