Re: drivers for l4-hurd

[M. Gerards]

Quoting Marcus Brinkmann <address@hidden>:

> On Wed, Nov 27, 2002 at 03:30:46PM +0100, Michal 'hramrach' Suchanek wrote:
> > Imho the translators should be configured passively so that they are
> started
> > when the device is needed.
> 
> I don't actually think you should start with filesystem integration here. 
> Adding filesystem interfaces to a device driver is opening a large can of
> worms, and you don't really want to worry about that.  Look at the proc
> server, it doesn't provide any filesystem interface, although it arguably
> could (/proc anyone?).
> 
> You definitely don't want to actually go through several process and
> filesystem layers in the communication.  Look at how careful libstore is
> written to not really go through /dev/hd0s1 etc in accessing the filesystem
> data.

You only have to go through the filesystem once AFAIK. The driver will give you
a object handle. Ofcourse when someone else wants to access the device it should
go through the filesystem again. Is this really a problem? I think drivers
aren't opened that often and when they are using filesystems as a namespace
won't slow things down significantly. I might be mistaken, please correct me :).


> Just a word of warning so that you don't fall for the old "if you only have
> a hammer, everything looks like a nail" trap.  Certainly you can make it
> look like a filesystem, but that doesn't mean it is useful or feasible.
> 
> In fact, I would think that for some things (Bus driver + device drivers)
> it's easier to have it all in one driver program with maybe dynamically
> loadable shared object modules.

You mean like the linux does with modules? I assume you want to put all drivers
in one address space. Isn't this a very monolithical solution? If one driver
crashes the whole system can go down under with it. 

-------------
Marco Gerards