Subject: lp support (Alpha level)
Date: Fri, 3 Jan 1992 02:32:11 EST
From: jim wiegand <V5068U%TEMPLEVM.BITNET@FINHUTC.hut.fi>
To: linux-activists@joker.cs.hut.fi
Hi Y'all;
here are the lp files. they aren't much right now but they will make
the printer go. (that reminds me- put a line in your init code somewhere that
calls void lp_init( void ). i forgot to put the file in the archive. oops)
right now i am working on the following (mis-) features :-)
o ioctl - to handle error recovery, translation, reset, etc.
o lpd - basic queue services
in that order.
and now for a few stupid questions:
what does the GNU getgroups() do? i wanted to compile cp(1) but make
barfed on this- not found.
is the message passing stuff going to be in the pipeline somewhere? i
am asking this because i need some sort of system log for the lpd.
what does POSIX say about printers & does anyone care?
thanks for the airtime. jim[v5068u].vm.temple.edu
---[cut here]---
Compressed
Subject: Re: lp support (Alpha level)
Date: Fri, 3 Jan 92 11:06:05 -0500
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: jim wiegand <V5068U%TEMPLEVM.BITNET@FINHUTC.hut.fi>
Cc: linux-activists@joker.cs.hut.fi
In-Reply-To: jim wiegand's message of Fri, 3 Jan 1992 02:32:11 EST,
Reply-To: tytso@athena.mit.edu
Date: Fri, 3 Jan 1992 02:32:11 EST
From: jim wiegand <V5068U%TEMPLEVM.BITNET@FINHUTC.hut.fi>
what does the GNU getgroups() do? i wanted to compile cp(1) but make
barfed on this- not found.
getgroups() is an optional POSIX system call, derived from BSD systems:
int ngroups = getgroups(int gidsetlen, gid_t *gidset)
(this is the POSIX definition. BSD systems have the type of gidset as
int, which is not the same as gid_t (unsigned short in BSD, and unsigned
char in Linux) --- this can be confusing)
This is used to support the feature where a user can be a member of more
than one group simultaneously. At login-time, login(1) uses the
setgroups() call to establish a list of groups that the user is in, and
this list is inherited by all child processes. When a groups-level
permission check is done, if any of the groups in the groups list match
the group of the file, then the user is given group access. The
getgroups() call is a way that the process can inquire about its group
list.
If cp(1) from the GNU fileutils is trying to use getgroups(), it sounds
like there's some sort of mis-configuration going on. Its .h files must
somehow think that it's being compiled on a BSD-like system. It sounds
like either something in the /usr/include .h files is tricking it to
believe that the getgroups() call exists on your system, or you need to
frob some #define's in the configuration header file of the fileutils
package. In general, I've found that programs which are told that it's
compiling on SysV R2 or R3 machine generally work.
Alternatively, someone could try adding setgroups()/getgroups() to
Linux --- this would be a good thing, since the BSD way is much easier
to use when you belong to multiple groups.
Date: Thu, 2 Jan 1992 19:51:55 -0700
From: Drew Eckhardt <drew@hazelrah.cs.Colorado.EDU>
Some one needs to get gdb up and running. Any takers?
Some one needs to get core dumps and/or ptrace() working first. :-)
The job control patches have a hook for the core dump routine, but it
hasn't been implemented yet. (I wanted to wait until after the VFS
stuff settles out.)
Another thing which would be really nice to get working would be
profiling --- both user-level and possibly kernel-level profiling would
be nice. Also, assuming you have a swap partition, it would be nice to
change linux to do crash dumps after it panics. In short, it looks like
there will be plenty of hacking for people to do after Linux 0.12 comes
out. :-)
- Ted
Subject: Re: lp support (Alpha level)
Date: Sat, 4 Jan 92 15:42:01 +1100
From: Bruce Evans <bde@runx.oz.au>
To: bde@runxtsa.runx.oz.au
Cc: linux-activists@joker.cs.hut.fi
>getgroups() is an optional POSIX system call, derived from BSD systems:
I thought it was a required POSIX system call.
> int ngroups = getgroups(int gidsetlen, gid_t *gidset)
>(this is the POSIX definition. BSD systems have the type of gidset as
>int, which is not the same as gid_t (unsigned short in BSD, and unsigned
>char in Linux) --- this can be confusing)
To handle this mess, fileutils-1.5 (which implements cp) has
#ifdef POSIX
#if !defined(sun) && !defined(ultrix)
#define GID_T gid_t
#else
#define GID_T int
#endif
#else
#define GID_T int
#endif
and it assumes (GID_T *) in the prototype. I think another gnu utilities
package uses GETGROUPS_T to allow for gid_t being different.
>...It sounds
>like either something in the /usr/include .h files is tricking it to
>believe that the getgroups() call exists on your system, or you need to
NGROUPS_MAX.
>Alternatively, someone could try adding setgroups()/getgroups() to
>Linux --- this would be a good thing, since the BSD way is much easier
Minix has { return 0; } for getgroups. This is good enough for fileutils
to work.
Bruce
Subject: Re: lp support (Alpha level)
Date: Mon, 6 Jan 92 14:31:59 -0500
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: linux-activists@joker.cs.hut.fi
In-Reply-To: [281]
Reply-To: tytso@athena.mit.edu
Date: Sat, 4 Jan 92 15:42:01 +1100
From: Bruce Evans <bde@runx.oz.au>
>getgroups() is an optional POSIX system call, derived from BSD systems:
I thought it was a required POSIX system call.
I stand corrected. It is required; I was getting confused by the fact
that NGROUPS_MAX can be 0, which means that there is no supplementary
groups support, and getgroups() will then also always return 0.
Minix has { return 0; } for getgroups. This is good enough for fileutils
to work.
I've fixed it by actually implementing getgroups() and setgroups(), as
well as POSIX_SAVED_IDS. Patches have been sent to Linus; if you want
to look at them, they can be found in TSX-11.MIT.EDU in
~ftp/ALPHA/job-control/grppatch.tar.Z. The patches are relative to
Linux 0.11 + the job control patches, but they shouldn't depend on the
job control changes except for silly things like system call numbering.
Note that programs which use the getgroups() call will depend on the
size of gid_t and will need recompiling when/if it gets changed. gid_t
is currently a unsigned char, but I would strongly recommend that at
some point we change it to be an unsigned short (at least). The problem
is that if we do this, all programs which use the stat() or fstat()
system call will also need recompiling.
Another change which is similar is MAXHOSTNAMELEN, which is currently 8.
To change it to something greater (I would suggest the BSD value of 64),
will require that all programs which use the uname() system call be
recompiled. No big deal, except that /bin/sh is one of them.
Neither of these are particularly important to make, so perhaps we
should batch up all of these changes and make them at some future point,
at which point everyone will have to recompile all their binaries.
- Ted