On Fri, Jan 18, 2008 at 04:44:37AM -0800, Richard L. Hamilton wrote: > > On Thu, Jan 17, 2008 at 07:26:25AM -0800, Joseph > > Balenzano wrote: > > > According to /etc/name_to_sysnum and syscall.h > > sytem calls 64 - 69 are reserved. Are they actually > > in use or just marked reserve for future development? > > > > > > > Marked for future development. > > > > But a general note: unless you're modifying the base > > kernel itself, > > don't use system calls. If your feature is > > separable, write a > > pseudo-driver and use ioctl() instead. > > > > -Mike > > There are existing implementations of add-on system calls: IIRS, OpenAFS > uses a syscall number (I seem to recall a collision on the default, last > time I tried to build it back in Solaris 9 timeframe - I had to pick an > unused number instead). Not that it exposed that interface to anything > other than AFS daemons or utilities...
I know. I've been over this with them before. There is no earthly reason for them to be using syscalls. They should be using ioctls. Same as what ZFS does for its control interface. > I've played around in my time with implementations of lchmod() and > even flink() (hard-link a name to a file descriptor on the same filesystem, > easier than it sounds, but uninteresting for me because other code > prevented it from working unless nlink was already greater than zero) > > I've mentioned them before, but not handed out the code, since back then > it was derived from limited access source; but also because I didn't want > folks creating dependencies on it. > > I'm told that the only case I found where lchmod() actually mattered > (needed write permission on a symlink in a sticky-bit directory to delete it) > was regarded as a bug, and went away; so unless one really has an urge > to see lrwxr-xr-x appear, there's no point to it; and as I said, the most > interesting case for flink() (restoring a name to an open-but-deleted file, > so that if one crashes, it goes away, but if one completes the output, > one can reassign it a name and have it persist) didn't work, so I'm not > sure how much of a point there would be to it either. They were both > more experiments in orthogonality than anything else. Those are things that clearly belong as system calls in the base kernel. > I do think someone ought to work with the OpenAFS folks, so that they > don't do things that cause problems; if they _really_ need a syscall, just > reserve them one, provided they understand they mustn't offer it as a public > interface. I've given them the input about 5 times over the past 10 years, because they keep filing bugs against Solaris. If you know who to talk to, feel free to talk to them and tell them to stop doing loadable syscall. > On the flip side, a few being reserved either for contracted 3rd party > stuff (which would have to be globally unique), or for experimenters that > might well have site-scope uses for them, might be handy, IMO. > > Presumably a loadable syscall is a private thing anyway, so any use of it > shouldn't be expected to be well-behaved unless it's integrated or contracted. Yes. Also there is no registry and the number space is highly constrained. The whole thing makes no sense. There should be a few slots for messing around, and then go download opensolaris and do whatever you like. I've yet to see ISV software using loadable syscalls that I thought should be. Everything I've seen in that space should be done using a pseudo-driver or implementing a per-filesystem xxx_ioctl() routine. Or by creating a custom brand using BrandZ because you're in essence trying to create an alternate kernel->userland personality for the system. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
