Hi,
Is there any particular reason we need a global errno in the kernel
at all? (which, by the way, doesn't seem to be subject to any kind of
locking) It makes life for User Mode Linux somewhat more complicated than
it could be, and it generally just seems a bad idea. Half a dozen places
in the kernel call syscalls from kernel space (the asm/unistd.h
__KERNEL_SYSCALLS__ stubs), but it sounds way better to change that limited
number to check the syscall return code instead of errno.
It appears that only one syscall stub caller checks syscall return value
anyway (exec_usermodehelper in kernel/kmod.c), so removing errno is quite
painless. Referenced patch deletes all mention of a global errno from the
kernel, and fixes up callers where necessary. I had to change definition
of _syscallX in various asm/unistd.h's not to use errno which might break
some userland, but userland shouldn't be touching these anyway.
Only tested on i386. Feedback appreciated, particularly experiences on
non-i386.
http://www.math.leidenuniv.nl/~buytenh/errno_ectomy-1.diff (33kb)
cheers,
Lennert
[email protected] said:
> Is there any particular reason we need a global errno in the kernel at
> all? (which, by the way, doesn't seem to be subject to any kind of
> locking)
As far as I've been able to tell, no.
> It makes life for User Mode Linux somewhat more complicated
> than it could be, and it generally just seems a bad idea.
Yeah. In order for -fno-common to not blow up the UML build (because of the
clash between libc errno and kernel errno), I had to add -Derrno=kernel_errno
to all the kernel file compiles. It would be nice to get rid of that wart.
> Referenced patch deletes all mention of a global errno from the
> kernel
Awesome. This definitely needs to happen. If no one spots any breakage,
send it in...
> and fixes up callers where necessary.
I did some grepping and the only problem I noticed was UML's execve (heh)
converting a -errno return to a -1.
Jeff
And can anybody explain, why is it so ?
(I mean checking for -1, and the switch(errno){}.)
AFAIK, syscall returns us a number (on i386 it is in eax)
and we can use it. Is errno a kernel thing, or GLIBC ?
Haven't we a return code in eax, after int 0x80 ?
(sorry, but I never worked on Linux on other architectures)
Best regards.
On Sun, 30 Dec 2001, Lennert Buytenhek wrote:
> Is there any particular reason we need a global errno in the kernel
> at all? (which, by the way, doesn't seem to be subject to any kind of
On Sun, Dec 30, 2001 at 02:56:21PM -0500, Jeff Dike wrote:
> [email protected] said:
> > Is there any particular reason we need a global errno in the kernel at
> > all? (which, by the way, doesn't seem to be subject to any kind of
> > locking)
>
> As far as I've been able to tell, no.
Historically the reason was to make unistd.h usable from userspace. Which
is causing tremendous portability problems so apps better shouldn't think
about using the syscall interface directly.
> > It makes life for User Mode Linux somewhat more complicated
> > than it could be, and it generally just seems a bad idea.
>
> Yeah. In order for -fno-common to not blow up the UML build (because of the
> clash between libc errno and kernel errno), I had to add -Derrno=kernel_errno
> to all the kernel file compiles. It would be nice to get rid of that wart.
>
> > Referenced patch deletes all mention of a global errno from the
> > kernel
>
> Awesome. This definitely needs to happen. If no one spots any breakage,
> send it in...
As user application are trying to use unistd.h and expect errno to get
set properly unistd.h or at least it's syscallX macros will have to be
made unusable from userspace or silent breakage of such apps rebuild
against new headers will occur.
Ralf
Ralf Baechle wrote:
>
> On Sun, Dec 30, 2001 at 02:56:21PM -0500, Jeff Dike wrote:
>
> > [email protected] said:
> > > Is there any particular reason we need a global errno in the kernel at
> > > all? (which, by the way, doesn't seem to be subject to any kind of
> > > locking)
> >
> > As far as I've been able to tell, no.
>
> Historically the reason was to make unistd.h usable from userspace. Which
> is causing tremendous portability problems so apps better shouldn't think
> about using the syscall interface directly.
>
> > > It makes life for User Mode Linux somewhat more complicated
> > > than it could be, and it generally just seems a bad idea.
> >
> > Yeah. In order for -fno-common to not blow up the UML build (because of the
> > clash between libc errno and kernel errno), I had to add -Derrno=kernel_errno
> > to all the kernel file compiles. It would be nice to get rid of that wart.
> >
> > > Referenced patch deletes all mention of a global errno from the
> > > kernel
> >
> > Awesome. This definitely needs to happen. If no one spots any breakage,
> > send it in...
>
> As user application are trying to use unistd.h and expect errno to get
> set properly unistd.h or at least it's syscallX macros will have to be
> made unusable from userspace or silent breakage of such apps rebuild
> against new headers will occur.
Userspace should be using glibc's unistd.h. If it's using the kernel's,
it's broken.
--
Brian Gerst
On Sun, Dec 30, 2001 at 07:00:20PM -0200, Ralf Baechle wrote:
> As user application are trying to use unistd.h and expect errno to get
> set properly unistd.h or at least it's syscallX macros will have to be
> made unusable from userspace or silent breakage of such apps rebuild
> against new headers will occur.
How about conditionalising definition of_syscallX on __KERNEL_SYSCALLS__?
(http://www.math.leidenuniv.nl/~buytenh/errno_ectomy-1-to-2.diff)
I guess I'll go ask all arch maintainers' permission now..
cheers,
Lennert
On Sun, Dec 30, 2001 at 05:10:41PM -0500, Brian Gerst wrote:
> > As user application are trying to use unistd.h and expect errno to get
> > set properly unistd.h or at least it's syscallX macros will have to be
> > made unusable from userspace or silent breakage of such apps rebuild
> > against new headers will occur.
>
> Userspace should be using glibc's unistd.h. If it's using the kernel's,
> it's broken.
A sufficient number take the unavailability of new syscall in everybody's
glibc as a sufficient excuse for broken code. util-linux as a major
offender comes to mind or also e2fsprogs.
Ralf
On Sun, Dec 30, 2001 at 08:52:57PM -0500, Lennert Buytenhek wrote:
> > As user application are trying to use unistd.h and expect errno to get
> > set properly unistd.h or at least it's syscallX macros will have to be
> > made unusable from userspace or silent breakage of such apps rebuild
> > against new headers will occur.
>
> How about conditionalising definition of_syscallX on __KERNEL_SYSCALLS__?
> (http://www.math.leidenuniv.nl/~buytenh/errno_ectomy-1-to-2.diff)
>
> I guess I'll go ask all arch maintainers' permission now..
Be careful, you'll have to fix at least util-linux (doubleplusyuck) and
e2fsprogs.
Ralf
Ralf Baechle <[email protected]> writes:
|> On Sun, Dec 30, 2001 at 05:10:41PM -0500, Brian Gerst wrote:
|>
|> > > As user application are trying to use unistd.h and expect errno to get
|> > > set properly unistd.h or at least it's syscallX macros will have to be
|> > > made unusable from userspace or silent breakage of such apps rebuild
|> > > against new headers will occur.
|> >
|> > Userspace should be using glibc's unistd.h. If it's using the kernel's,
|> > it's broken.
|>
|> A sufficient number take the unavailability of new syscall in everybody's
|> glibc as a sufficient excuse for broken code. util-linux as a major
|> offender comes to mind or also e2fsprogs.
Userspace should be using syscall(2/3) for new syscalls.
Andreas.
--
Andreas Schwab "And now for something
[email protected] completely different."
SuSE Labs, SuSE GmbH, Schanz?ckerstr. 10, D-90443 N?rnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
On Mon Dec 31, 2001 at 12:01:20AM -0200, Ralf Baechle wrote:
> On Sun, Dec 30, 2001 at 08:52:57PM -0500, Lennert Buytenhek wrote:
>
> > > As user application are trying to use unistd.h and expect errno to get
> > > set properly unistd.h or at least it's syscallX macros will have to be
> > > made unusable from userspace or silent breakage of such apps rebuild
> > > against new headers will occur.
> >
> > How about conditionalising definition of_syscallX on __KERNEL_SYSCALLS__?
> > (http://www.math.leidenuniv.nl/~buytenh/errno_ectomy-1-to-2.diff)
> >
> > I guess I'll go ask all arch maintainers' permission now..
>
> Be careful, you'll have to fix at least util-linux (doubleplusyuck) and
> e2fsprogs.
You say this as if having util-linux and e2fsprogs etc get fixed
would be a bad thing... I personally think this would be a very
good change, and would let the kernel enforce good programming style,
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
On Mon, Dec 31, 2001 at 05:48:09PM +0100, Andreas Schwab wrote:
> |> A sufficient number take the unavailability of new syscall in everybody's
> |> glibc as a sufficient excuse for broken code. util-linux as a major
> |> offender comes to mind or also e2fsprogs.
>
> Userspace should be using syscall(2/3) for new syscalls.
Which just replaces one problem with another, slightly smaller one.
So something like syscall(SYS_pwrite, fd, buf, count, pos) will not work
on all architectures because pos is a 64-bit argument which as to be
passed in an aligned register pair on some machines, so an additional
argument has to be inserted. So the glorious attempt to use syscall()
will now write data to fantasy positions in a file. Great. And just
an example demonstrating that the syscall interface is seriously dangerous
and non-portable. I don't think there is anyway except people limiting
themselfes APIs provided by libc or similar but not using syscalls directly.
Ralf