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.
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
------------------------------------
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/
|