Re: [PLUG] Re: dynamic file (script output)

["Kyle R . Burton" <mortis@voicenet.com>]

> Erm. Not so much. I don't actually know how the HURD does this, but
> I'd guess it's much like what Kyle Burton described in his PLUG post.
> Only but extensible. That really shouldn't be that hard to hack into
> fs code. (Where my scale of hard *might* be a bit skewed by all the
> beating on UVM I've been doing lately, but whatever.)
> 
> That said, Kyle, the problem with your make-a-device technique is
> that it only works for one very specific purpose. (Want more than
> one file that does this? A file that does something different? Add
> another kernel module!) Martin (and now, I, I suppose) want
> something that can be told what to do when any inode in the file
> system is accessed, presumably through an interface similar to
> Solaris's {s,g}etfacl routine.

Well, you could write a generic module that took as a parameter (at lsmod
time) the cmdline of a program you wanted it to execute and act as a 
pipe for.  You could also use a configuration file that mapped a file
name to a command line to exec -- the module could load that table and create
the proper device nodes (which might not need to be in /dev) to which
open requests could be mapped [piped] to a forked/execed program.

It's dangerous to play with the kernel this way, and a security risk, but
I can see how you could do it -- though I don't think it'd be trivial.

> The socket stuff you want isn't hard, and yes, it's quite possible
> to make a daemon open a FIFO, spit stuff into it, and toss that
> out over NFS, even forking children to read from the FIFO if that's
> your cup of tea... Kyle's description of a daemon to speak text
> cat'ed into it (through some text-to-speech software) gives a better
> example than I could.
> 
> What that doesn't fix, though, is interleaving input to the FIFO
> and waiting for the FIFO to recylce. UDP isn't any better on the
> first point (though it's got promise on the second).
> 
> Yes, but you'll have many of the same problems you did with a FIFO.
> (So, I guess, "no" to the second part.)
> 
> ... and UDP has no guarantee of delivery to boot! Whee!

Unix domain sockes and UDP are not the same thing -- UDP is user
datagram protocol (IIRC), while unix domain sockets are restricted 
to localhost specificly because the operate through files.  I've never
explored these kinds of issues with unix domain sockets -- that 
approach just might get you what you're looking for.

k

-- 
------------------------------------------------------------------------------
"From a certain point onward there is no longer any turning back.  That is the
 point that must be reached."   -- Kafka
mortis@voicenet.com                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------


______________________________________________________________________
Philadelphia Linux Users Group       -      http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion  -  http://lists.phillylinux.org/mail/listinfo/plug