[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

   > 	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: