[Top][All Lists]

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

Re: Initial target(s) for libmob

From: olafBuddenhagen
Subject: Re: Initial target(s) for libmob
Date: Sat, 30 May 2009 06:50:01 +0200
User-agent: Mutt/1.5.18 (2008-05-17)


On Fri, May 29, 2009 at 04:18:55PM +0200, Carl Fredrik Hammar wrote:
> On Thu, May 21, 2009 at 06:44:59PM +0200, olafBuddenhagen@gmx.net
> wrote:

> I was going to refute your suggestion of ioctl handlers, but in
> arguing about it back and forth with myself, I ended up agreeing with
> you.  ;-)

Hehe :-)

> > ioctl()s are always specific to a particular device class, and thus
> > the server(s) implementing (or proxying) it. It makes perfect sense
> > for a server implementing a specific device, also to provide the
> > ioctl wrappers necessary to access it.
> I agree that ioctls are device specific, but not that they are
> specific to the server.  If the client makes use of an ioctl, then it
> must be aware of the device class as well.  A header must be provided
> that defines macros for the ioctl numbers, it does not seem
> unreasonable to also provide a module with the corresponding handlers
> at the same time.

Actually, the header is normally provided by the kernel, isn't it? And
thus, the entity implementing the drivers... So, my point stands :-)

> Investigating ioctls a bit closer it seems that glibc already provides
> some provisions to register additional handlers.  I think its possible
> to do everything needed from a linked object file by simply linking to
> it, i.e. without any function calls.

Interesting -- didn't know about this.

> The only real problem here is that we are required to link the
> application with the specific handler library.  A step that isn't
> needed on other OSes.

Note that the whole ioctl support is only for compatibility with
non-hurdish applications. Having to do anything special on the
application side would go against this goal... Although changing a
program to link an additional module is of course easier than changing
it to not use ioctls at all, it's still indiscutable I'd say.

> Rather it should be enough to link with glibc, and for easy
> extensibility no change to glibc should be required to add new ioctls.
> This means glibc has to dynamically link with an ioctl handler module.
> Which leaves the question of how to find it.


> Broadly speaking there are only two options; either the device
> specifies it or a system service does.  The system service can be
> quite mundane, as my original suggestion of simply loading a library
> based on the device class name.  Note that the name would have to be
> encoded into the ioctl number, or looked up in a file e.g.
> /etc/ioctltab, otherwise glibc would need to be hacked in order to add
> new device classes.  It could also be a more sophisticated system
> server, possibly giving out handlers using libmob as in your
> suggestion.


> Lets look at this from the perspective of a non-root user who wants to
> provide a device of a new device class.  This is the sort of thing the
> Hurd is all about.  ;-)

...that's just what I was thinking when reading the paragraph above :-)

As I already said in the unionmount discussion (regarding the hidden
nodes), we generally want to avoid centralized services, unless really
necessary. When the thing can be negotiated between the server and the
client directly, why introduce a central service? It only complicates
stuff and limits possibilities.

(Note that the Hurd doesn't have a central VFS implementation for
example -- it's all between servers and clients!)

> One issue with encoding the handler module name in the ioctl is that
> it requires changing the current numbering convention.

No idea what you mean :-(

> Another interesting issue is ioctl clashes, i.e. that two distinct
> ioctls share the same number but differ in semantics and possibly
> parameters and their types.

Is that possible on other systems? Otherwise, the only case where I
could see that happen, would be if we want to emulate ioctl()s from more
than one other system...

> In the device case, the ioctl handler from the first device used will
> be used.  Still not an ideal situation, but chances are better that
> the client wishes to use the ioctl of a device it has actually tried
> to use.  Though, it will fail if it first tries a device that
> implements a clashing ioctl and then use one that implements the
> wanted ioctl. It also can never use more than one of the clashing
> ioctls.


> The only way to handle clashes is they would be on other OSes would be
> to keep distinct ioctl handlers for each file descriptor.  This would
> make use of proper mobile objects, and not just the same code loading
> mechanism.  Though the objects would be trivial, and only used as
> function pointer tables.

...again, just what I was thinking when reading the above paragraph...

> This would require changing how ioctl are handled in glibc, but I
> believe the end result would be simpler and less reliant on linker
> magic, such as the use of symbol lists.

...and I also concluded that this is probably indeed simpler and more
natural. Although it's a bigger change from the way glibc handles it so
far, it's closer to the other uses of the mobility framework (and thus
might actually be less work), and generally more logical IMHO.

> However, I also want to get a thesis out of this and I don't think
> server loaded ioctl handlers would be enough on their own.

I think they actually might -- but I don't know the expectations there,
so I can't really tell...

> My initial use-case so far has been to use mobile objects for
> optimization, i.e. to use a local copy of an object to avoid RPCs in a
> transparent fashion.

Well, I always considered translator stacking optimization the main use
case -- in fact the only real use case, until the ioctl() idea came
up... And even that is quite similar technically, even if the goal is
very different.

(As I said elsewhere, I think that joining instances of similar
translators *might* be another use case, that would be more different --
but as also stated there, I don't know yet whether this is indeed a job
for the mobility framework at all.)

Thus, when talking about use cases, I was thinking about more specific
things. Moving libstore to use the more generic framework, seems the
only other realistic target here... We don't really have any other cases
that employ translator stacking at any meaningful scale so far.

> As such I have been considering refocusing my thesis solely on the
> optimization use-case.

That's what I was trying to suggest over the last couple of mails :-)

> However, it would be hard to fit ioctls in to this.  Though I guess I
> could state that the long term goal is a general mobility framework,
> but that I choose to focus on two immediate use-cases.

Yeah, something along these lines. I don't think it should be a problem.

> However, I would like to finish my thesis before the next opportunity
> to hand it in for review, which is September 2.  So I'm mostly worried
> that implementing ioctls will keep me from completing it on time.

It seems to me that the ioctl() use case should be almost trivial
compared to the optimization one. It shouldn't require much aside from
the common components of the framework I would think, which you would
need for the latter anyways...


reply via email to

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