Russell Coker writes:
> 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?
Correct. Is that so bad?
> 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.
What bothers me is that in time, people will call for other C library
functions to be wrapped. Bloat, bloat, bloat. I don't want to set a
trend. So if instead we have a nowarn option, people have a way of
shutting up symlink(2), and it sets the trend to use options. The
number of options asked for will likely be less than the number of C
library wrappers.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|