In <200002172307.PAA32027@pell.portland.or.us> david parsons (orc@pell.portland.or.us) wrote:
> Riley Williams wrote:
>>
>> Hi David.
>>
>> >>>>> it would mount as another logical volume. Now when there was a
>> >>>>> need to access the first floppy, the OS popped up a dialog ( a
>> >>>>> requester, in amiga terminology :-) saying "Insert volume
>> >>>>> Linux_help_disk into any drive". When the user
>>
>> >>>> Ahem... OK, does anyone else see something strange in words "OS
>> >>>> popped up a dialog"?
>>
>> >>> On a real operating system, the OS would simply notify userland,
>> >>> which would do whatever it wanted to do.
>>
>> >> Fair enough so far. It's from here on that things go wrong.
>>
>> >>> A sensible userland might then spit out a dialog telling the
>> >>> user...
>>
>> >> Which user's screen should that dialogue appear on?
>>
>> > Who cares?
>>
>> {Shrug} If you don't care about kernel issues, you shouldn't be here.
> It's not a kernel issue. Why should the lkml care about
> reinventing userspace things? Just off the top of my head I can
> think of an implementation of a userspace disk-change notifier that
> doesn't require anything more than some sort of {SEYMOUR FEED ME}
> callback, and I'm sure that the people who do it for a living can
> think of a whole bunch of other ways to do it.
Since till such deamon is designed it's not clear which information is
needed by such daemon. For example it can be usefull to notify owner of
process which tries to use floppy. To do so you SHOULD know such owner
and it's not possible to do from userspace.
>> > It's a >>USERLAND PROBLEM<< and once the notify gets out of
>> > kernelspace it's not a lkml problem anymore.
>> Personally, I can't see any point in writing a single line of kernel
>> code to address this issue
> You're planning on writing the kernel glue, and are waiting for a
> userland interface?
Kernel glue is ANSOLUTELY useless without userland interface. Thus such
glue MUST be developed with userland interface.
> Qool. Give me a procfs or devfs pipe that
> I can hang a daemon off to pick up {FEED ME, SEYMOUR!} requests,
> a mount option that lets me specify the socket name (I suggest
> ``notifier=filename'' -- the path to it can be fixed), and tweak
> the driver code so that iff there's a notifier pipe and the media
> isn't there, it spits a one-byte message up the pipe, otherwise
> it fails in the normal way.
> It won't be hard to tweak mount so that if there's a notifier=
> option on a mount and the mount command is run from a tty, it
> will launch a notifier daemon. The notifier daemon will be
> attached to the users tty, so if they hang up, it will die and
> unmount the offending filesystem, otherwise it will simply
> spit "feed me!" messages as appropriate.
> ____
> david parsons \bi/ It's an ugly interface, but what do you expect for
> \/ 20 seconds of thought?
Exactly. That's why THE whole scheme should be designed (complete with
userland daemon) BEFORE talks about submitting changes to Linus can be
started. Otherwise the same thing will happen as with LinuxThreads.
Clone allowed the beast to be created. Just like you proposed no one tried
to actually write userspace part early. So now we ALMOST have "proper"
implementation (not 100% ready BTW). THREE YEARS after interface was folded
in kernel ? Why ? Since three years ago noone bothered to write userspace part
and find out that you'll need few small additions to kernel to do things
"right way". Additions not exactly obvious when userspace was not implemented.
Not a way to go IMNSHO.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:23 EST