[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