Linux-Development-Sys Digest #764, Volume #7 Wed, 12 Apr 00 22:13:18 EDT
Contents:
Re: schedule_timeout() (Kaz Kylheku)
Re: struct passwd * (bill davidsen)
Re: struct passwd * (Kaz Kylheku)
Re: To core or not to core - You tell me (Erik Max Francis)
Re: Kernel development (Nathan Dorfman)
Re: struct passwd * (Juergen Heinzl)
system call pre-emptable ??? (Badrinath Venkatachari)
Re: struct passwd * (Juergen Heinzl)
Re: system call pre-emptable ??? (Kaz Kylheku)
How ready is 2.3.99preN? (Dale Pontius)
Re: To core or not to core - You tell me (Michael Rubenstein)
Linux Ports (Pat Finnegan)
LILO 21.4 update (John in SD)
Re: Q: is there a free secure network filesystem for Linux? (Christopher Browne)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: schedule_timeout()
Reply-To: [EMAIL PROTECTED]
Date: Wed, 12 Apr 2000 22:15:14 GMT
On Wed, 12 Apr 2000 16:32:11 -0500, Aurelie Fonteny <[EMAIL PROTECTED]>
wrote:
>Hi,
>I want to delay a task for 1 s. This task is inside of a transmission
>procedure for a network device driver. So here is how it looks like :
>
>start_bh_atomic();
><CODE>
>current->state = TASK_UNINTERRUPTIBLE;
>schedule_timeout(HZ);
><CODE>
>end_bh_atomic();
No no no! You must not reschedule in a bottom half or interrupt context. Prior
to calling schedule_timeout, you must do end_bh_atomic.
>When I run the driver and it goes to this part of the code, nothing is
>responding anymore : mouse is not working, I can't type anything..., and I
>just can do a reset! And when I delete the two line with current->state ans
>schedule_timeout(), it's working fine.
>Does anyone know why?
Read the ``scheduling in interrupt'' panic message on the console. ;)
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: struct passwd *
Date: 12 Apr 2000 22:17:09 GMT
In article <[EMAIL PROTECTED]>,
Juergen Heinzl <[EMAIL PROTECTED]> wrote:
| The official documentation is pretty clear regarding that and in can
| be boiled down to ...
| () if you need the returned value copy the contents.
| ... and that is it, full stop, no room left for any interpretation.
That wasn't the question of the original poster, and I don't believe
anyone has said you didn't need to copy the data.
| There is no memory leak either, this is, sorry, nonsense.
Having worked with many crappy libraries I lack your faith in them. If a
man page says that the route can get an "out of memory" error, I assume
that the memory is allocated dynamically, and if you do that often
enough you will (I've watched it happen in other cases) leak memory.
Allocating memory the first time through is the worst of all possible
worlds, so that's probably what it does. You open the possibility of
failing to allocate, and the struct is so small the static buffer is
smaller than the code it takes to allocate it (if you error check)!
The original poster assumed (1) that if you could get an error
allocating memory memory was being allocated. And (2) that if you
didn't free it you had a memory leak.
Even if this is just piss-poor misleading documentation, and one or the
other of those assumptions is incorrect, I don't find either of those
two assumptions "nonsense." Sounds like defensive programming to me.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
"Doing interesting things with little computers since 1979"(tm)
The hardest test of maturity is knowing the difference between
resisting temptation and missing a once-in-a-lifetime opportunity.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: struct passwd *
Reply-To: [EMAIL PROTECTED]
Date: Wed, 12 Apr 2000 22:33:57 GMT
On 10 Apr 2000 20:16:48 GMT, bill davidsen <[EMAIL PROTECTED]> wrote:
>
>In article <[EMAIL PROTECTED]>,
>Dan McGuirk <[EMAIL PROTECTED]> wrote:
>| bill davidsen wrote:
>| > Someone have the source for glibc handy? I don't, and I'm not going to
>| > go grab it.
>|
>| You don't need the source, just the documentation. From the glibc
>| manual:
>
> I'm looking at a Redhat 5.2 man page right now, and it doesn't say
>anything like that, and even warns that you can get ENOMEM if there's no
>memory available to allocate.
getpwuid does not allocate, and should not set errno to ENOMEM.
See its defintion in The Single UNIX Specification online draft:
http://www.opengroup.org/onlinepubs/007908799/xsh/getpwuid.html
> Oops, RH did change something, or the library implementation changed,
>I checked a 6.1 machine, and it does say static, but it also reports
>the same error message. Obviously you can't get a memory unavailable if
>you have a static allocation, perhaps they save the result of the first
>dynamic allocation and reuse it. Another case for the source code.
The library used on Red Hat is the GNU C Library. It's not a feature
of Red Hat. Redhat 6.1 is based on glibc-2.1.2, I think.
You just have to jump to the online CVS repository for glibc to see what
getpwuid does.
Between the CVS repository and The Single UNIX Spec, you're covered.
http://sourceware.cygnus.com/cgi-bin/
cvsweb.cgi/libc/pwd/getpwuid.c?cvsroot=glibc
This file just sets up some macros and then includes a common source snippet
which uses macro preprocessing to generate the function. The history for that
is here:
http://sourceware.cygnus.com/cgi-bin/
cvsweb.cgi/libc/nss/getXXbyYY.c?cvsroot=glibc
This generic function works by guessing at the buffer size and calling the
reentrant version of the function, in this case getpwuid_r. If the buffer
is too small, it is realloc'ed to be bigger and the reentrant function is
tried again.
> Unfortunately, you really *must* know which it is, since you don't
>want to free a static buffer, but if you don't free a dynamic buffer you
>leak memory.
Memory is leaked when it becomes unreachable. This buffer happens to be a
*singleton*: a dynamically allocated global object that persists over the
lifetime of the program. That's not a leak, since the buffer is reachable right
until the program terminates.
--
#exclude <windows.h>
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Wed, 12 Apr 2000 15:33:17 -0700
Mark McIntyre wrote:
> Agreed. I'm talking about NULL, the macro which 6.3.2.3 and 7.17 in
> the ANSI/ISO C standard defines as the null pointer constant.
But you said "the bit pattern of NULL," which doesn't make sense,
because NULL is a macro. Macros don't have bit patterns. What you mean
is the bit pattern representation of the _null pointer_, which is
specified by a null pointer constant -- either 0 in a pointer context or
(void *) 0 -- and which, incidentally, the NULL _macro_ is defined as.
But NULL itself doesn't have a bit pattern.
The reason people are replying to correct you is not that you are
totally wrong, it's just that you're using sloppy terminology. All the
people who are presently participating in this thread are saying
precisely the same thing, we're just at the nitpick level now.
--
Erik Max Francis | email [EMAIL PROTECTED] | icq 16063900
Alcyone Systems | web http://www.alcyone.com/max/ | q3a Product
San Jose, CA | languages en, eo | icbm 37 20 07 N 121 53 38 W
USA | 969.729 Ms p.L. | 263 days left | &tSftDotIotE
__
/ \ To understand is to forgive, even oneself.
\__/ Alexander Chase
------------------------------
From: Nathan Dorfman <[EMAIL PROTECTED]>
Subject: Re: Kernel development
Date: 12 Apr 2000 18:59:20 EDT
Philip wrote:
>
> Ivan Van den Bossche wrote:
> >
> > Hello everybody,
> >
> > Where can I find the right documentation on the WEB to get started with
> > Kernel development? What do I need to know?
> >
>
> C
I'm going to assume you're already aware of that requirement, and
provide you
with somewhat more useful references:
OS design theory and other kernel implementations (these are books):
The Design and Implementation of the 4.4BSD Operating System (you've
heard of BSD, right?)
by Kirk McKusick, Keith Bostic, Michael Karels.
Addison-Wesley, May 1996, ISBN 0201549794
Operating Systems (this is the 2nd edition, may be a newer one, check)
by William Stallings
Prentice Hall, Oct 1994, ISBN 0024154938
Operating Systems: Design and Implementation, 2nd Ed. (MINIX code
in-line with text, very good)
by Andrew S. Tanenbaum
Prentice Hall PTR, Jan 1997, ISBN 0136386776
For more advanced stuff look at other books by Tanenbaum. He is a
generally well-respected
operating systems expert and most of his books are quite insightful. He
has one called
'Modern Operating Systems' as well as 'Distributed Operating Systems',
namely.
The Linux kernel in particular (these are online resources):
The Linux Kernel (http://www.linuxdoc.org/LDP/tlk/tlk.html)
Linux Kernel Hacker's Guide
(http://www.linuxdoc.org/LDP/khg/HyperNews/get/khg.html)
I can't really say whether you should read the latter two first, with
Linux sources, of
course, or one or two of the physical books (the 4.4BSD book should go
with either 4.4BSD
source or FreeBSD/OpenBSD/NetBSD) ... you'll have to figure that out for
yourself.
> --
> Philip van Hoof aka freax _/_/_/
> http://users.pandora.be/skatan _/_/ _/ _/_/ _/_/_/ _/_/ _/ _/
> mailto:[EMAIL PROTECTED] _/_/ _/ _/ _/ _/ _/ _/ _/
> Microsoft OS are bad, and _/_/_/_/ _/ _/ _/_/ _/_/_/_/ _/_/
> their morals are even worse _/_/ _/ _/ _/ _/ _/ _/
> (Linus Torvalds 8 Sept.1996)_/_/ _/ _/_/_/ _/ _/ _/ _/
--
Nathan Dorfman <[EMAIL PROTECTED]> [http://www.rtfm.net]
"The light at the end of the tunnel is the headlight of an approaching
train." --/usr/games/fortune
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: struct passwd *
Date: Wed, 12 Apr 2000 23:09:24 GMT
In article <8d2sl5$2p5$[EMAIL PROTECTED]>, bill davidsen wrote:
>
>In article <[EMAIL PROTECTED]>,
>Juergen Heinzl <[EMAIL PROTECTED]> wrote:
>
>| The official documentation is pretty clear regarding that and in can
>| be boiled down to ...
>| () if you need the returned value copy the contents.
>| ... and that is it, full stop, no room left for any interpretation.
>
>That wasn't the question of the original poster, and I don't believe
>anyone has said you didn't need to copy the data.
[...]
Just for the sake of completeness.
>| There is no memory leak either, this is, sorry, nonsense.
>
>Having worked with many crappy libraries I lack your faith in them. If a
>man page says that the route can get an "out of memory" error, I assume
>that the memory is allocated dynamically, and if you do that often
>enough you will (I've watched it happen in other cases) leak memory.
[...]
Please read the available documentation, not just the man page, again.
Memory might or might not be allocated, depending on the implementation,
but if so, then it will be allocated *once* !!
If allocated, then this buffer is going to be re-used and may be
free'd whenever the implementation thinks it is okay, so to say.
[...]
>The original poster assumed (1) that if you could get an error
>allocating memory memory was being allocated. And (2) that if you
>didn't free it you had a memory leak.
[...]
(2) is wrong. Again, there is no "it is the callers responsibility
to call free()" or something similar around and computers do not like
people making assumptions.
>Even if this is just piss-poor misleading documentation, and one or the
>other of those assumptions is incorrect, I don't find either of those
>two assumptions "nonsense." Sounds like defensive programming to me.
[...]
It is not defensive but wrong, sorry. There is no such thing as 73%
right code. Would you write code like ...
free( ptr );
free( ptr ); /* just in case the first free() did not work */
... ? No, sure you would not.
libc.x.y.1 is free to use a static buffer, libc.x.y.2 is free to
use allocated memory, libc.x.y.3 is free to use a shared memory
area and libc.x.y.4 is free to use something no-one has ever heard
about and in all cases the implementation is free to return a pointer
into a buffer, read the returned address may not even be equal
to &buffer[0].
If I am sounding quite anal here, fine with me as if it comes to
coding I am like that.
Take care,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: Badrinath Venkatachari <[EMAIL PROTECTED]>
Subject: system call pre-emptable ???
Date: Wed, 12 Apr 2000 19:28:50 -0700
Hi,
If I blocked the immediate processing of a read() request in the
kernel, (by say Qing the request, waiting for sometime and then issuing
the request after sometime, while the process (in the kernel) that
issued the request waited on a wait_queue, would it be possible to
receive requests from other processes ??
In other words, can other read() system calls result in a context
switch while I am yet to issue the pending request ??? I want to be able
to Q requests from multiple processes before servicing them. (assume
that the mechanism to make the requesting process (in the kernel) wait
on a wait_queue has been established and it can be woken up properly).
thanks a lot in advance
badri
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: struct passwd *
Date: Wed, 12 Apr 2000 23:51:09 GMT
In article <8d2sl5$2p5$[EMAIL PROTECTED]>, bill davidsen wrote:
>
>In article <[EMAIL PROTECTED]>,
>Juergen Heinzl <[EMAIL PROTECTED]> wrote:
>
>| The official documentation is pretty clear regarding that and in can
>| be boiled down to ...
>| () if you need the returned value copy the contents.
>| ... and that is it, full stop, no room left for any interpretation.
>
>That wasn't the question of the original poster, and I don't believe
>anyone has said you didn't need to copy the data.
[...]
Yes, for the sake of completeness although it should tell people
something, as if the same memory area is being re-used there
either cannot be a memory leak or the implementation in question
is a complete brain dead one, as some effort is being required
to end up with memory leaking.
>| There is no memory leak either, this is, sorry, nonsense.
>
>Having worked with many crappy libraries I lack your faith in them. If a
>man page says that the route can get an "out of memory" error, I assume
>that the memory is allocated dynamically, and if you do that often
>enough you will (I've watched it happen in other cases) leak memory.
[...]
If the documentation for some arbitrary function mentions memory is
being allocated but not that it is the callers responsibility to free
it, then either doing so means a bug in the code or not doing so
means a bug in the documentation. Time to get things sorted out,
not to write code in the hope it does the right thing.
[...]
Bye,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: system call pre-emptable ???
Reply-To: [EMAIL PROTECTED]
Date: Thu, 13 Apr 2000 00:46:00 GMT
On Wed, 12 Apr 2000 19:28:50 -0700, Badrinath Venkatachari <[EMAIL PROTECTED]>
wrote:
> In other words, can other read() system calls result in a context
>switch while I am yet to issue the pending request ??? I want to be able
Of course; otherwise your getty's call to read() on the console to get the
login name would freeze the system. ;)
------------------------------
From: [EMAIL PROTECTED] (Dale Pontius)
Subject: How ready is 2.3.99preN?
Date: Wed, 12 Apr 2000 19:53:46 -0400
for limited usage. I'm about to move my firewall machine up to
RedHat 6.2, and it's kind of tempting to move it to 2.3.99 at
about the same time, and start playing with netfilters.
It's a Tyan Tomcat I (Triton HX chipset)
with an NE2k clone
and a Hercules monographics clone
Pretty vanilla hardware. It seems to me that most of the problems
with 2.3.xx are with more obscure or newer hardware.
Dale Pontius
------------------------------
From: Michael Rubenstein <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Wed, 12 Apr 2000 20:59:02 -0400
On 12 Apr 2000 17:59:12 -0400, [EMAIL PROTECTED] (Paul D.
Smith) wrote:
>%% Mark McIntyre <[EMAIL PROTECTED]> writes:
>
> mm> "An integer constant expression with the value 0, or
> mm> such an expression cast to type void *, is called a null
> mm> pointer constant."
>
> mm> This says that either its (int)0
>
>Since we're picking nits, (int)0 is not an integer constant. You mean
>just 0 (or 0L or 0U or 0UL).
Since we're picking nits, (int)0 is an integral constant
expression which is what the definition of a null pointer
constant calls for. See the standard, 6.4 (C90).
You are correct that a null pointer constant need not have type
int. 0L, 0U, 0UL, or (char)0 are all null pointer constants.
------------------------------
From: Pat Finnegan <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.unisys
Subject: Linux Ports
Date: Wed, 12 Apr 2000 20:03:48 -0500
I have recently acquired (actually a few months ago now, I guess) a
Unisys U5000 minisystem. Running off of a 68020 at 25MHz, it may not
be the fastest system out there, but I would still like to put it to
some use.
Does anyone know of a Linux Port that'll work with it? From what
research I've done, it looks bleak, however; I might be willing to
take on the task if anyone has good hardware specs (I'd work on
porting either uClinux or m68k - the Amiga port, probably, to it) that
they could send me or point me towards. I think I'd rather port the
2.0 branch rather than a newer branch, though, so I might actually be
able to finish it this year ;) - I am attending college now so my time
is kinda limited. If anyone else could lend a hand or offer
information, etc. please email me.
Thanks!
-- Pat Finnegan, Hardware revivalist
------------------------------
From: John in SD <[EMAIL PROTECTED]>
Subject: LILO 21.4 update
Reply-To: [EMAIL PROTECTED]
Date: Thu, 13 Apr 2000 01:25:36 GMT
LILO version 21 by Werner Almesberger has been updated to support
booting from large capacity disks using a new 'lba32' option (-L new
command line switch). Dubbed version 21.4, the source code is
available for download from:
ftp://sd.dynhost.com/pub/linux/lilo (developer's site)
ftp://brun.dyndns.org/pub/linux/lilo (an alias)
Or from the main distribution site:
ftp://metalab.unc.edu/pub/Linux/system/boot/lilo
The lilo-21.4.2 release fixes problems that have affected a few
people:
1. The command line passed to the kernel was truncated at 78
characters if the LARGE_EBDA (Extended BIOS Data Area) compile-time
option was used. (With today's big kernels, this was the default.)
2. If both 'linear' and 'compact' were specified, the second stage
loader would encounter disk I/O error 0x40.
Enhancements include:
3. The boot loader now understands octal. The kernel has always
understood octal, decimal, and hexadecimal, but prior boot loaders
only supported the last two.
4. All patches from the RedHat 6.2 distribution have been applied.
This includes the RAID support.
This version of LILO will boot from partitions beyond the 1024
cylinder limit. To do this it requires a post-1998 BIOS with support
for the EDD packet call interface. Older systems may employ "soft"
BIOS support for these calls with hard disk boot software such as
EZ-DRIVE(tm) or MaxBlast(tm).
--John Coffman <[EMAIL PROTECTED]>
EZ-DRIVE(tm) is a registered trademark of Micro House International,
Inc.
MaxBlast(tm) is a trademark of Maxtor, Inc.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Q: is there a free secure network filesystem for Linux?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 13 Apr 2000 01:50:30 GMT
Centuries ago, Nostradamus foresaw a time when Michael Pronath would say:
>Is there a network filesystem, that has useful security features (i.e. not
>NFS), and is free and open source available for Linux (i.e. not AFS) ?
>What would you use for a small LAN, Home Office or so? Samba?
SAMBA is probably the simplest option to provide "more
connection-oriented security than NFS offers."
But I'd have to question why you _truly_ feel a need for that. In the
environments you describe, users tend to have physical access to all
the hardware, which means that you really don't have any more security
underlying things than NFS has.
--
If you stand in the middle of a library and shout "Aaaaaaaaargh" at
the top of your voice, everyone just stares at you. If you do the same
thing on an aeroplane, why does everyone join in?
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
