Date: Sat, 18 Nov 1995 11:28:45 +0100 (MET) From: grog@lemis.de (Greg Lehey) To: bde@zeta.org.au (Bruce Evans) Cc: hackers@freebsd.org (FreeBSD Hackers) Subject: Re: linux' mknod and named pipes. Message-ID: <199511181028.LAA17511@allegro.lemis.de> In-Reply-To: <199511180923.UAA17204@godzilla.zeta.org.au> from "Bruce Evans" at Nov 18, 95 08:23:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans writes:
>
> >> >Is there any good reason why we shouldn't modify mknod to make a fifo
> >> >when called with the appropriate parameters?
> >>
> >> The same reason we shouldn't modify thousands of other system calls to be
> >> compatible with thousands of other systems: it takes longer and gives
> >> worse results.
>
> >I think that bears discussion.
>
> >1. It takes longer:
>
> >--- vfs_syscalls.c 1995/11/14 09:19:16 1.40
> >+++ vfs_syscalls.c 1995/11/18 08:45:43
> >@@ -757,6 +757,13 @@
> > int error;
> > struct nameidata nd;
> >
> >+ if (ISFIFO (uap->mode))
> >+ {
> >+ struct mkfifo_args args;
> >+ args.path = uap->path;
> >+ args.mode = uap->mode;
> >+ return mkfifo (p, args);
> >+ }
> > error = suser(p->p_ucred, &p->p_acflag);
> > if (error)
> > return (error);
>
> > OK, I haven't tested this, but it's got to be something like it.
> > In the normal case, there's a single 'if' involved.
>
> It takes longer to write, document, commit and test. Perhaps even as
> long as to argue about it :-).
Nah, never!
> >2. It gives worse results. How? Why?
>
> It just confuses programmers to have two ways of doing the same thing.
Not if you say "this feature is deprecated and only exists for
compatibility with obsolescent operating systems".
> The p flag to mknod(8) isn't supported either.
Don't let me ask why not :-)
Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511181028.LAA17511>