help-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Repeater for the console client


From: Marcus Brinkmann
Subject: Re: Repeater for the console client
Date: Wed, 21 Jul 2004 15:46:55 +0200
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Wed, 21 Jul 2004 02:51:09 +0200,
marco_g wrote:
> 
> Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> writes:
> 
> >> 2) Using netfs to create /dev/console/ (the path is configurable, of
> >>    course) in which translators can be stored.  This requires a change
> >>    to the console client.  In that case the console client sets up the
> >>    /dev/console/ translator and drivers can use some special function
> >>    to set up a translator in that directory.
> >
> > Mh.  I think you can also do several nodes in trivfs, so using netfs
> > is not mandatory to get the same effect.  However, in either case the
> > console client would need to provide an intermediate layer and
> > interfaces to plugins.  Seems to make sense to me to do it that way.
> 
> The problem with that would be that there is just a single global to
> configure if the file can be opened read, write or readwrite.

Well, we can always make the global allow everything, and be prepared
for everything in the stubs.
 
> Other that that, I just like having everything in a single directory
> like /dev/console which is entirely virtual.

As I said, I think you can use trivfs to that effect.

> So I would prefer using libnetfs.  What would you like to see (and of
> course, accept)?

It's no big deal.  Whatever makes you feel comfy.  Using libtrivfs for
anything more complicated than a single file node is usually a bit
awkward, file netfs seems to evolve into a more generic approach, so
use it if you feel like that.
 
Thanks,
Marcus




reply via email to

[Prev in Thread] Current Thread [Next in Thread]