Re: New thoughts about deva/fabrica

[Peter 'p2' De Schrijver]

> (Actually, this is probably a serious downside of the deva/fabrica
> proposal. For those that aren't tracking it: Neal is working on a nice
> resource management framework, in which applications, in a hurdish
> manner, announce their own resource needs, and the manager fills them as
> good as possible while keeping fairness, using a market-based approach.
> Being among the most performance-relevant tasks in the system, with
> real-time behaviour and all, the drivers obviously need to make
> extensive use of the possibilities offered here. However, this resource
> management interfaces will be inherently Hurd-specific (or at least I
> see no feasable way to make it generic), thus defeating the whole idea
> of a system independant driver framework...)

The resource framework can be used by any l4 process and is by no means
hurd specific.

> 
> 3. RPC. This is actually the only point where overhead can be really
> performance-relevant. Luckily, this is also the one least affected by my
> proposal.
> 
> While I strongly encourage using filesystem semantics unless there are
> good reasons not to, there is nothing in my proposal making them
> mandatory for all interfaces. I explicitly mention that while the
> majority of drivers probably won't experience any relevant performance
> hit, for the few ones that would, it is perfectly possible, valid, and
> desirable to implement shortcuts in the form of optimized custom RPC
> protocols.
> 

Except that filesystem semantics are generally very inappropriate as a
driver interface. POSIX style filesystems generally deal with byte
streams, while drivers almost always work with some form of blocks
(network packets, disk blocks, ...) While you can quite easily map a byte 
stream into packets, the reverse is much harder as you need to delimit
('frame') the data. The normal POSIX read/write functions don't do this,
which makes them inappropriate as an interface for most devices.

> 
> On a completely different note, there are some considerations to make
> deva a library instead of a server. While this may sound like a simple
> substitution, it really makes it much closer to the POSIX driver
> proposal than to the original approach. The one remaining fundamental
> difference is that instead of accessing the Hurd facilities through libc
> using POSIX, it would access them through the deva library using some
> special deva interfaces. I wonder, what for?
> 

Because most drivers don't work with streams while the POSIX and libc
I/O calls don't know anything but streams.

p2.

signature.asc
Description: Digital signature