Re: Deva interface

[Marcus Brinkmann]

At Sun, 16 Jan 2005 06:26:19 -0500,
Neal H. Walfield wrote:
> >  Mach used strings to name the devices, but I think this would be
> >  difficult to do if we don't support string items.
> 
> Why?  Do you really thing device names will be longer than 63 (the
> number of message resiters not including MR0) * (sizeof l4_word_t)
> characters?

I think the answer is that we will support string items.  That should
be simpler (and maybe even faster) than frobbing message registers.

What we can do for deva/ddf is to have a relatively small upper limit
for string items, let's say 4K (if we want to support it for inline
read/write, too), or some other small convenient constant.  The only
grief is that this memory has to be allocated up-front by the server
for every worker thread in a server thread pool that wants to allow
string items (well, we _could_ play some pager tricks to avoid that
requirement).

I should say that supporting inline read/write is a very important
optimization, and this alone would justify the use of string items.

Changes to libhurd-cap-server to support string items shouldn't even
be excessively large.  You could even implement multiple options:
Allocating the string item buffer on the stack, or via mmap, or via
malloc (probably leave it to malloc if mmap or malloc should be used),
or why not even via libhurd-slab, although there is no initialization.
We know some statistical properties of such memory areas (the
beginning will be more utilized than the end, etc), so there should be
some sort of optimization possible.
 
> >  So a collection of numbers (like the major and minor on UNIX, except
> >  that we can use words to store these number and thus not fearing not
> >  to have enough numbers) could be a good idea to identify a device.
> 
> Maybe.  Names are nicer but we can see what is more convenient later.

Both approaches have their benefits.  You can also map from one naming
scheme to another (well, going from arbitrary names to numbers is a
bit hard, but with a flexible number space, it is possible).

I don't think it's a big issue either way.
 
> > I hope that these interfaces match what you've been thinking of.
> 
> I see no reason not to support some subset of hurd/fs.defs and
> hurd/io.defs (however, they will look on the Hurd/L4 port) in this
> way, deva can be a proper Hurdish filesystem translator.

Indeed.  Actually, I don't think it is very important to have deva
actually provide a filesystem - stability, security, efficiency and
performance are overriding priorities.  A cross between mach's
device.defs and hurd's io.defs seems appropriate to me.  Or in other
words: io.defs on crack for the extra device specialities.

Thanks,
Marcus