Linux-Development-Sys Digest #240, Volume #6 Sat, 9 Jan 99 00:14:31 EST
Contents:
Re: blocksize / file write speed anomaly (Bernd Strieder)
Re: Can't reboot at root from "xdm" (Brett W. McCoy)
Re: simple problem with libc6 (Daniel R. Grayson)
Re: PCMCIA support under 2.1.131 - how? (Daniel R. Grayson)
STREAMS ("Dan McNaul")
Re: disheartened gnome developer ("Bob Taylor")
Re: socket question (Tony R. Bennett)
current->files 2.2.0pre4 (David Grothe)
Re: boot problems with 2.2.0-pre5 ("P.K.")
Re: Glibc2.0.7 crypt files Yes/No ? (Daniel R. Grayson)
Re: disheartened gnome developer ("Bob Taylor")
Re: make xconfig ("P.K.")
Re: Registry for Linux - Bad idea (Frank Sweetser)
Re: Registry for Linux - Bad idea (Frank Sweetser)
----------------------------------------------------------------------------
From: Bernd Strieder <[EMAIL PROTECTED]>
Subject: Re: blocksize / file write speed anomaly
Date: Fri, 08 Jan 1999 15:09:36 +0100
Hi
Paul Popowski wrote:
>
> If you look where the bottleneck in your program occurs it's at the point where you
>call
> fsync.
> The man page for fsync even acknowledges that for some applications the function
>fdatasync
> would
> be a better choice. Running your program with fsync (in the random write) changed to
> fdatasync I get
> the exact same results as the first part of the test actually even better in some
>cases.
>
> pops
using fdatasync instead of fsync doesn't change anything for me.
Using kernel 2.0.36 and SCSI.
Nice Weekend !
--
/|||\ Bernd Strieder
c+O-O+c
# | # HP: http://www.student.uni-kl.de/~strieder
##-##
###
------------------------------
From: [EMAIL PROTECTED] (Brett W. McCoy)
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.setup,comp.os.linux.x
Subject: Re: Can't reboot at root from "xdm"
Reply-To: [EMAIL PROTECTED]
Date: Fri, 08 Jan 1999 15:14:57 GMT
On Thu, 07 Jan 1999 00:24:31 +0000, Jon D. Slater <[EMAIL PROTECTED]> wrote:
>Once I log in as root using an XDM login, I've noticed if I type
>"reboot" or "reboot &" in an xterm my machine does not reboot until I
>press <Alt><Ctrl><F1>, switch to a "text based" screen.
>
>Then the machine (running Redhat 5.2) reboots normally.
>
>Why can't I reboot my machine from within an XDM login session?
>
>Or maybe my question sould be "How do I reboot from an xterm run under
>an XDM login?"
I think you have to be at runlevel 3 to be able to shutdown (which then
takes the system to runlevel 0, 1, or 6). Check the man pages for more
information.
--
Brett W. McCoy
http://www.lan2wan.com/~bmccoy/
=======================================================================
"The number of UNIX installations has grown to 10, with more expected."
-- The UNIX Programmer's Manual, 2nd Edition, June, 1972
=====BEGIN GEEK CODE BLOCK=====
Version: 3.12
GAT dpu s:-- a C++++ UL++++$ P+ L+++ E W++ N+ o K- w--- O@ M@ !V PS+++
PE Y+ PGP- t++ 5- X+ R+@ tv b+++ DI+++ D+ G++ e>++ h+(---) r++ y++++
======END GEEK CODE BLOCK======
------------------------------
From: [EMAIL PROTECTED] (Daniel R. Grayson)
Subject: Re: simple problem with libc6
Date: 08 Jan 1999 09:13:39 -0600
The answer is in glibc.info - you can arrange it so read() terminates *or*
continues after an interrupt.
File: libc.info, Node: Interrupted Primitives
Primitives Interrupted by Signals
=================================
A signal can arrive and be handled while an I/O primitive such as
`open' or `read' is waiting for an I/O device. If the signal handler
returns, the system faces the question: what should happen next?
POSIX specifies one approach: make the primitive fail right away.
The error code for this kind of failure is `EINTR'. This is flexible,
but usually inconvenient. Typically, POSIX applications that use signal
handlers must check for `EINTR' after each library function that can
return it, in order to try the call again. Often programmers forget to
check, which is a common source of error.
The GNU library provides a convenient way to retry a call after a
temporary failure, with the macro `TEMP_FAILURE_RETRY':
- Macro: TEMP_FAILURE_RETRY (EXPRESSION)
This macro evaluates EXPRESSION once. If it fails and reports
error code `EINTR', `TEMP_FAILURE_RETRY' evaluates it again, and
over and over until the result is not a temporary failure.
The value returned by `TEMP_FAILURE_RETRY' is whatever value
EXPRESSION produced.
BSD avoids `EINTR' entirely and provides a more convenient approach:
to restart the interrupted primitive, instead of making it fail. If
you choose this approach, you need not be concerned with `EINTR'.
You can choose either approach with the GNU library. If you use
`sigaction' to establish a signal handler, you can specify how that
handler should behave. If you specify the `SA_RESTART' flag, return
from that handler will resume a primitive; otherwise, return from that
handler will cause `EINTR'. *Note Flags for Sigaction::.
Another way to specify the choice is with the `siginterrupt'
function. *Note BSD Handler::.
When you don't specify with `sigaction' or `siginterrupt' what a
particular handler should do, it uses a default choice. The default
choice in the GNU library depends on the feature test macros you have
defined. If you define `_BSD_SOURCE' or `_GNU_SOURCE' before calling
`signal', the default is to resume primitives; otherwise, the default
is to make them fail with `EINTR'. (The library contains alternate
versions of the `signal' function, and the feature test macros
determine which one you really call.) *Note Feature Test Macros::.
The description of each primitive affected by this issue lists
`EINTR' among the error codes it can return.
There is one situation where resumption never happens no matter which
choice you make: when a data-transfer function such as `read' or
`write' is interrupted by a signal after transferring part of the data.
In this case, the function returns the number of bytes already
transferred, indicating partial success.
This might at first appear to cause unreliable behavior on
record-oriented devices (including datagram sockets; *note
Datagrams::.), where splitting one `read' or `write' into two would
read or write two records. Actually, there is no problem, because
interruption after a partial transfer cannot happen on such devices;
they always transfer an entire record in one burst, with no waiting
once data transfer has started.
------------------------------
From: [EMAIL PROTECTED] (Daniel R. Grayson)
Subject: Re: PCMCIA support under 2.1.131 - how?
Date: 08 Jan 1999 09:14:54 -0600
Get the pcmcia stuff separately from [EMAIL PROTECTED]:/pub/pcmcia
------------------------------
From: "Dan McNaul" <[EMAIL PROTECTED]>
Subject: STREAMS
Date: Fri, 8 Jan 1999 10:35:20 -0500
This is a multi-part message in MIME format.
=======_NextPart_000_0080_01BE3AF2.97216F40
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
Does anyone know if the Linux kernal supports the STREAMS sub-system?
If it does, do you know where the header files are located?
Thanks
McNaul
=======_NextPart_000_0080_01BE3AF2.97216F40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Hi,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Does anyone know if the Linux kernal =
supports=20
the STREAMS sub-system?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>If it does, do you know where the =
header files=20
are located?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Thanks</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>McNaul</FONT></DIV></BODY></HTML>
=======_NextPart_000_0080_01BE3AF2.97216F40==
------------------------------
Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] ("Bob Taylor")
Subject: Re: disheartened gnome developer
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Date: Sat, 09 Jan 1999 04:01:43 GMT
In article <[EMAIL PROTECTED]>,
Victor Danilchenko <[EMAIL PROTECTED]> writes:
[snip]
>
> If EVERYTHING was free, people would not need jobs. That's communism --
> working because you want to, not because you have to.
>> is that what you want? no jobs?
>
> Not a bad idea, actually, but it will never work as long as there are
> selfish people willing to take advantage of it.
Please study the subject (communism) before spouting off. Firstly *nothing*
is free. Under classic communism, *everybody works for the common good*.
What do you suppose your neighbors would do to you if *you* sat on your duff
and didn't *work*?
--
+---------------------------------------------------------------+
| Bob Taylor Email: [EMAIL PROTECTED] |
|---------------------------------------------------------------|
| Like the ad says, at 300 dpi you can tell she's wearing a |
| swimsuit. At 600 dpi you can tell it's wet. At 1200 dpi you |
| can tell it's painted on. I suppose at 2400 dpi you can tell |
| if the paint is giving her a rash. (So says Joshua R. Poulson)|
+---------------------------------------------------------------+
------------------------------
From: [EMAIL PROTECTED] (Tony R. Bennett)
Subject: Re: socket question
Date: 8 Jan 1999 07:40:56 -0800
In article <[EMAIL PROTECTED]>,
Mr Patrick Ian Mackinlay <[EMAIL PROTECTED]> wrote:
>If I get a 0 return code from a recv call on an open socket, does that
>mean that the socket has stalled (i.e. there still may be some
>information on the way) or that there is no information left to come?
>
>cheers
>
>Patrick
That means the socket is now disconnected...
--
Anti-spam filter: I am not root@localhost
trb@teleport dot com COM Public Access User --- Not affiliated with Teleport
------------------------------
From: David Grothe <[EMAIL PROTECTED]>
Crossposted-To: revue.linux-kernel
Subject: current->files 2.2.0pre4
Date: 8 Jan 1999 16:33:58 +0100
Reply-To: [EMAIL PROTECTED]
I have a character driver that when its open routine is called for the
first time the pointer current->files is NULL. This in spite of the
fact that the sys_open routine has just used that pointer a few
instructions ago.
This happens with the kernel compiled with SMP set. If I unset SMP then
there is no problem. I notice that there is a difference in how task
structures are allocated depending upon the SMP switch but it is not
obvious to me that this is the problem.
I realize that this is not much of a hint, so if anyones wants to chase
this, e-mail me directly and I'll see what I can do to gather more
information.
Version info:
$ cat /proc/version
Linux version 2.2.0-pre4 ([EMAIL PROTECTED]) (gcc version
2.7.2.3) #5 Thu Jan 7 12:55:07 CST 1999
-- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "P.K." <[EMAIL PROTECTED]>
Subject: Re: boot problems with 2.2.0-pre5
Date: Sat, 09 Jan 1999 05:24:12 +0100
Frank Hale wrote:
> I just installed the kernel 2.1.132 and patched it too 2.2.0-pre5 then I
> compiled it and installed it and when I boot I get the following
> messages
>
> Jan 8 04:22:23 localhost kernel: klogd 1.3-3, log source = /proc/kmsg
> started.
> Jan 8 04:22:23 localhost kernel: Cannot find map file.
> Jan 8 04:22:23 localhost kernel: Error seeking in /dev/kmem
> Jan 8 04:22:23 localhost kernel: Error adding kernel module table
> entry.
> Jan 8 04:22:23 localhost kernel: Linux version 2.2.0-pre5
>
> Its not loading my modules and doesn't work correctly after boot. I
> copied the System.map file over too /boot/ and changed the symlink to
> point to my new System .map and I have done everything I could think of
> to get it too load the modules still it does not. What am I missing
> here? Thanx.....
>
Hi.
When installing v2.1.132, did you also installed latest modutils? You must
also recompile syslogd/klogd in order to work properly.
Bye,
Peter.
------------------------------
From: [EMAIL PROTECTED] (Daniel R. Grayson)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Glibc2.0.7 crypt files Yes/No ?
Date: 08 Jan 1999 09:15:56 -0600
Matt Zagni <[EMAIL PROTECTED]> writes:
> Hi,
>
> I have found the Glibc2.0.7 files (locale and the others)
> but I am unable to find a Glibc2.0.7 crypt file for that
> release. Is there any need for the crypt files ?
>
> I can find the Glibc2.0.9 version but that fails to compile.
>
> Many thanks
>
> Matt
Use the 2.0.6 version.
------------------------------
Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] ("Bob Taylor")
Subject: Re: disheartened gnome developer
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Date: Sat, 09 Jan 1999 04:01:42 GMT
In article <[EMAIL PROTECTED]>,
kristian ragndahl <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] ("Bob Taylor") writes:
>
>: if eveything is free, companies will close, and there will be no jobs.
>
> If everything is free, whyever would you need a job?
Watch your step there fella! I *most certainly didn't write that*! I
responded to it!
--
+---------------------------------------------------------------+
| Bob Taylor Email: [EMAIL PROTECTED] |
|---------------------------------------------------------------|
| Like the ad says, at 300 dpi you can tell she's wearing a |
| swimsuit. At 600 dpi you can tell it's wet. At 1200 dpi you |
| can tell it's painted on. I suppose at 2400 dpi you can tell |
| if the paint is giving her a rash. (So says Joshua R. Poulson)|
+---------------------------------------------------------------+
------------------------------
From: "P.K." <[EMAIL PROTECTED]>
Subject: Re: make xconfig
Date: Sat, 09 Jan 1999 05:27:48 +0100
Frank Hale wrote:
> Hello I just recently downloaded kernel 2.1.132 and am trying to get it
> installed under RH 5.2. I untar'd it and did make xconfig and after I
> finish configuring the kernel it tells me
>
> WARNING - broken Config.in! CONFIG_PMAC was not declared!
> WARNING - broken Config.in! CONFIG_APOLLO was not declared!
> WARNING - broken Config.in! CONFIG_MAC was not declared!
> WARNING - broken Config.in! CONFIG_HP300 was not declared!
> WARNING - broken Config.in! CONFIG_FB_MAC was not declared!
> WARNING - broken Config.in! CONFIG_FB_G364 was not declared!
> WARNING - broken Config.in! CONFIG_FB_TBOX was not declared!
> WARNING - broken Config.in! CONFIG_FB_MDA was not declared!
> WARNING - broken Config.in! CONFIG_FB_VGA was not declared!
> WARNING - broken Config.in! CONFIG_AMIGA was not declared!
> WARNING - broken Config.in! CONFIG_ARM was not declared!
> WARNING - broken Config.in! CONFIG_ATARI was not declared!
> WARNING - broken Config.in! CONFIG_PPC was not declared!
> WARNING - broken Config.in! CONFIG_ZORRO was not declared!
> WARNING - broken Config.in! CONFIG_ARCH_ACORN was not declared!
> WARNING - broken Config.in! CONFIG_ARCH_ARC was not declared!
> WARNING - broken Config.in! CONFIG_ARCH_A5K was not declared!
> WARNING - broken Config.in! CONFIG_MIPS_JAZZ was not declared!
> WARNING - broken Config.in! m was not declared!
> WARNING - broken Config.in! CONFIG_ALPHA_BOOK1 was not declared!
>
> Does anyone know what these messages mean? The kernel compiles with no
> errors.
>
I think this warnings are kind of 'normal' , you don't get them when
doing 'make menuconfig'.
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 08 Jan 1999 11:46:45 -0500
Johan Kullstam <[EMAIL PROTECTED]> writes:
> George MacDonald <[EMAIL PROTECTED]> writes:
>
> > Nice solution! That handles the new conventions on linux perfectly.
> > Linux seems a bit more organized and better thought out than other
> > unix implementations, well at least with regards to configuration.
> >
> > I would like one file that is higher up than than appconf.d that
> > allows the location of appconf.d to be configured. My reasoning is that
> > on other unix's the /etc area is in root is sometimes quite small, so may
> > not be capabable of holding it. I can envisage other systems
> > wanting to put the "appconf.d" directory in /usr/lib or usr/share,
> > ... I kind of like the linux way, but perhaps we should allow for
> > the placement elsewhere.
>
> put user application configuration in /usr/etc. place systems/boot
> stuff in /etc. this mirrors the /usr/bin v /bin and /usr/sbin v /sbin
> splits.
only the top level metadata file has to be known before hand, probably a
compile time setting. everything else can be specified in there, making it
just local policy.
> also, there's no need for the `conf.d' part. simply being part of
> /etc means its a configuration file. the `d' can maybe stay but i
> think that's redundant too.
<shrug> that's just the naming convention redhat uses, so that's why i
suggested it.
> if the application has *one* configuration file, it could be a
> straight file under the appropriate etc directory. if the application
> has more than one file, make a directory.
not neccessary. the /etc/opStore.d/<app> file does not contain the
settings for <app>, it only contains information on the location(s) to get
the settings for <app>.
> it it not so clear how to manage shared data, i.e., two applications
> want the same data (e.g., bash and csh both want a default path. i'd
> be nice to maintain one and have the other follow automatically).
> perhaps links (hard or soft) would be useful.
make a "shells" configuration category. opStore.d/bash, opStore.d/csh, etc
would then just including the shells config category and automagically get
access to the default path, along with any other settings needed to be
shared. however, the path is something generic enough that i think it
should go in a global category.
which suggests another feature - instead of each layer only having the
option of accepting/replacing the previous level's value, it might also
want to re-write it. ie, take the organization default path, add any
system local paths, etc etc.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre3 i586 | at public servers
A "goto" in Perl falls into the category of hard things that should be
possible, not easy things that should be easy.
-- Larry Wall in <[EMAIL PROTECTED]>
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 08 Jan 1999 11:45:48 -0500
Johan Kullstam <[EMAIL PROTECTED]> writes:
> George MacDonald <[EMAIL PROTECTED]> writes:
>
> > Nice solution! That handles the new conventions on linux perfectly.
> > Linux seems a bit more organized and better thought out than other
> > unix implementations, well at least with regards to configuration.
> >
> > I would like one file that is higher up than than appconf.d that
> > allows the location of appconf.d to be configured. My reasoning is that
> > on other unix's the /etc area is in root is sometimes quite small, so may
> > not be capabable of holding it. I can envisage other systems
> > wanting to put the "appconf.d" directory in /usr/lib or usr/share,
> > ... I kind of like the linux way, but perhaps we should allow for
> > the placement elsewhere.
>
> put user application configuration in /usr/etc. place systems/boot
> stuff in /etc. this mirrors the /usr/bin v /bin and /usr/sbin v /sbin
> splits.
only the top level metadata file has to be known before hand, probably a
compile time setting. everything else can be specified in there, making it
just local policy.
> also, there's no need for the `conf.d' part. simply being part of
> /etc means its a configuration file. the `d' can maybe stay but i
> think that's redundant too.
<shrug> that's just the naming convention redhat uses, so that's why i
suggested it.
> if the application has *one* configuration file, it could be a
> straight file under the appropriate etc directory. if the application
> has more than one file, make a directory.
not neccessary. the /etc/opStore.d/<app> file does not contain the
settings for <app>, it only contains information on the location(s) to get
the settings for <app>.
> it it not so clear how to manage shared data, i.e., two applications
> want the same data (e.g., bash and csh both want a default path. i'd
> be nice to maintain one and have the other follow automatically).
> perhaps links (hard or soft) would be useful.
make a "shells" configuration category. opStore.d/bash, opStore.d/csh, etc
would then just including the shells config category and automagically get
access to the default path, along with any other settings needed to be
shared. however, the path is something generic enough that i think it
should go in a global category.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre3 i586 | at public servers
A "goto" in Perl falls into the category of hard things that should be
possible, not easy things that should be easy.
-- Larry Wall in <[EMAIL PROTECTED]>
------------------------------
** 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
******************************
