On Wed, 7 Nov 2001 07:18, Richard Gooch wrote:
> > error calling: "symlink" in "GLOBAL"
> > error calling: "symlink" in "GLOBAL"
> > error calling: "symlink" in "GLOBAL"
> >
> > When you do "killall -1 devfsd" to reload the config you often see errors
> > such as the above. These are because of "CFUNCTION GLOBAL symlink"
> > events trying to create the link a second time.
> >
> > I have attached a patch that fixes this issue. It has special case
> > code for "GLOBAL symlink" which calls an internal function instead
> > of the libc function (to preserve config file compatibility). This
> > function does the usual symlink operation but gives no error message
> > when the link as desired is already there (if you ask for "symlink
> > $devname modem" and there is already a symlink /dev/modem pointing
> > at /dev/$devname then it's not an error IMHO). When there is a real
> > error it gives slightly more information.
> >
> > Richard, please consider this for inclusion in the main tree.
>
> Sorry, but I hate it. The worst offence is to put special-case hacks
> into the parser. That's just too ugly for words. I'm also uneasy about
> wrapping C-library functions.
I was half expecting that response.
> My preferred solution to this (something I've been thinking about
> for a while because it's generally useful) is to allow options to be
> specified for actions. So you would have something like this:
> REGISTER ^cdrom/cdrom0$ CFUNCTION,nowarn GLOBAL symlink cdroms/cdrom0
> cdrom
So we don't warn if the user tries to create a symlink in a non-existant
directory, try to replace a device node with a symlink, or do any of the
other possible errors?
If we're going to change the config file then why not make it:
REGISTER ^cdrom/cdrom0$ CFUNCTION GLOBAL devsymlink cdroms/cdrom0 cdrom
Then we have a devsymlink() function internal to devfsd which does something
similar to what I've proposed.
> Comments? Yes, I know it requires a config file change, but tough.
> Even if I were to allow a symlink wrapper, I'd still force a config
> file change. Magic re-interpretation of libc is not an option.
OK. But I'll leave the magic re-interpretation in the Debian package until
we come up with something better...
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
|