Re: more interfaces for the lsb spec
Date: Wed, 14 Feb 2001 20:04:22 +0000 (GMT)
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> ptrace for debugging/development only
You can do a lot more with ptrace. Also please consider that ISV's products
include debuggers
Good point. Ok, so we need a volunteer for someone to write up a
specification for ptrace.
> mount system call should only be used by system programs
> umount system call should only be used by system programs
> umount2 system call should only be used by system programs
So we are requiring installers shell out to do mounting of media. There are
also other cases where mount is essential, such as back up systems. Im
not sure which is the right choice
Mount has all sorts of special case options for mounting different
filesystems, especially remote networking filesystems. I'm *sure* we
don't want to standardize that.
And once you start including raid and LVM volumes and loop filesystems,
I suspect that encouraging backup systems to shell out to /sbin/mount
might not be the better choice....
I'd claim that mount isn't going to be a speed critical operation,
shelling out isn't a major difficulty. But I could go either way about
specifying the use of mount only where the last argument (the const void
*) must be NULL.
> Questionable:
> mknod obvious, do we think applications call this directly?
> POSIX.1 ducked defining this. Should we?
Xfree uses it for one. We also need to define mkfifo if we dont define
mknod.
I think we probably will have to define mknod. Anyone know off-hand if
SUS defines mknod and mkfifo?
> Malloc extensions, should probably remove
> =========================================
>
> memalign
> valloc
valloc is used in a _lot_ of BSD originated codebase and some SYS5. Its
just sort of useful.
Are there really that many programs that use this feature? Unless
you're doing some kind of direct I/O, you generally don't care about
major alignment issues. The only thing I can think of that would care
would be an X server --- is there anything else. (Of course, that along
might be enough, but if that's the case, we'll need to check what other
requirements an X server might need --- like iopl() and ioperm(), for
example.)
> Defined in POSIX.2
> ==================
> getopt
Our getopt isnt strictly posix compliant for sanity reasons, so that needs
noting. Also we want everyone to use the getopt_long stuff 8)
Yup, we need someone to write up a spec which details how our getopt
differs from POSIX.2's getopt, and we need someone to write up a
getopt_long and friends spec.
- Ted
Reply to: