Linux-Development-Sys Digest #523, Volume #6 Wed, 24 Mar 99 01:14:20 EST
Contents:
Re: sleep_on (Wlmet)
Re: PPP Dial-Up Insomnia (Bill Unruh)
Re: PPP Dial-Up Insomnia (Whammy)
Re: Building Linux (Adrian 'Dagurashibanipal' von Bidder)
Re: sleep_on (Alexander Viro)
Re: Fast IPC (low-latency for small messages) (Leslie Mikesell)
Source for SYSV 'banner' (Tony Scholes)
Re: Where should I look for the source for 'cp'? (Thomas Zajic)
Re: Where should I look for the source for 'cp'? (Thomas Zajic)
Re: Where should I look for the source for 'cp'? (David T. Blake)
Network protocol layer in Linux ? ([EMAIL PROTECTED])
meteor module doesn't want to unload (Conrad Sanderson)
Re: Where should I look for the source for 'cp'? (Thomas Zajic)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Wlmet)
Subject: Re: sleep_on
Date: 23 Mar 1999 23:22:52 GMT
>>static inline void __sleep_on(struct wait_queue **p, int state)
>>{
>> unsigned long flags;
>> struct wait_queue wait = { current, NULL };
>>
>> if (!p)
>> return;
>> if (current == task[0])
>> panic("task[0] trying to sleep");
>> current->state = state;
>> add_wait_queue(p, &wait);
>> save_flags(flags);
>> sti();
>> schedule();
>> remove_wait_queue(p, &wait);
>> restore_flags(flags);
>>}
>>
>>
>>I am not clear on what happens here if the process loses the CPU right after
>
>>current->state = state;
> Erm... It's not "if", it's "when". As soon as it calls schedule(),
>indeed. Nothing can force the context-switch against the will of process in
>kernel mode, so it will succefully put itself on the wait queue and then
>request the context-switch by schedule() call. Then it will be excluded from
>further scheduling until something will move it into the TASK_RUNNING state
>(or will deliver a signal for interruptible ones - same mechanism). Then it
>will be eligible for CPU again.
> "Something" mentioned above is wakeup() issued later - that's the
>whole point of wait queues. We are excluding ourselves from scheduling
>until something will do wakeup(p). remove_wait_queue() will be done when
>that will happen and we'll get CPU. It's a cleanup - we don't want to be
>bothered by further wakeup(p) (and in this case we'ld better clean after
>ourselves - element of wait queue we've added is on stack and we are going
>to return.
>
>
>>If state is not interruptible, than it seems that the process would be stuck
>>here.
> Yup. That's exactly what we want to achieve. Get stuck until the event
>will happen. Think of wait queues as sleeping places. Process registers
>itself
>there by add_wait_queue() and gets a nap. wakeup(&queue) means "wake up
>everybody who registered at this queue".
Doesn't the timer interrupt call schedule() regularly. What if it calls
schedule() right after this process changes its state? It seems to me that it
will get stuck there if its new state is not interruptible.
Obviously, it doesn;t because the code works but I am missing something.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: ahn.tech.linux,alt.os.linux,comp.os.linux.hardware
Subject: Re: PPP Dial-Up Insomnia
Date: 11 Mar 1999 21:30:27 GMT
In <7c9165$kos$[EMAIL PROTECTED]> "Igor Raznatovic" <[EMAIL PROTECTED]> writes:
>For couple of days I am trying to set up my dial up account. Teh result was,
>not incouraging. For now, my modem is dialing out nicely. The school BBS was
>easy to acces. My ISP? No.
...
>the same with the GNOME ppp utility, the terminal screen showed that same
>messege minicom showed (System Password:). I called my ISP and he said that
This almost certainly means that they do NOT want you to log on, they
want ppp to start right after the CONNECT message.
See my
axion.physics.ubc.ca/ppp-linux.html
to find out exactly what they want and how to set it up for them.
Most of the scripts are set up for login authorisation, while most ISPs
are going for PAP/CHAP authorisation.
------------------------------
From: Whammy <[EMAIL PROTECTED]>
Crossposted-To: ahn.tech.linux,alt.os.linux,comp.os.linux.hardware
Subject: Re: PPP Dial-Up Insomnia
Date: Thu, 11 Mar 1999 22:11:08 GMT
Is your ISP 'INTX'? They want you to use PAP for the login procedure.
(Note: the other access number for these guys uses the standard
username/password procedure. You may want to try it.) You will need to
set up PPP to use the pap-secrets file to get this connection to work.
INTX also doesn't work with compressed headers so disable this in the
pppd command string.
Igor Raznatovic wrote:
>
> For couple of days I am trying to set up my dial up account. Teh result was,
> not incouraging. For now, my modem is dialing out nicely. The school BBS was
> easy to acces. My ISP? No.
>
> Somewhere I read that calling through minicom can get me started with some
> info in my ISP, so I dialed it. Thies is what I got:
> ===========================================
> Welcome to InterSATX
>
> System Password:
>
> I closed minicom and tried netconf. I've set it up as the HOWTO said and it
> dieled nicely but after about 1 min the connection died. When I tried to do
> the same with the GNOME ppp utility, the terminal screen showed that same
> messege minicom showed (System Password:). I called my ISP and he said that
> my ppp is not starting and that is why this message shows up. I have a
> static IP address so I would like to have that option enabled.
> Please send me info on the critical files that need to be changed to get the
> thing going. After all this I want to try to configure it manually.
------------------------------
From: [EMAIL PROTECTED] (Adrian 'Dagurashibanipal' von Bidder)
Subject: Re: Building Linux
Date: Tue, 23 Mar 1999 22:08:19 GMT
On Tue, 23 Mar 1999 01:42:33 GMT, [EMAIL PROTECTED] wrote:
>[...]I want to build from scratch
>so I can learn more about the OS.
=46orget about cross-compiling if your point is to learn about the
inner working of a Linux distribution. Do it if you know a lot about
gcc and want to learn even more.
If you want to learn about the kernel, plunge into driver
programming. If you want to learn about the system, install a
distribution, maka a second partition and copy a kernel, lilo, init,
a shell, standard tools and a gcc to it - but take care that you
understand what every file you copy does.
Have a _very_ close look at the /etc/inittab file (of your working
out-of-the-box distro) and all files mentioned therein - they are
controlling the computer once the kernel has mounted root read-only.
Once you have gcc working on your new Linux installation, you may
want to delete the old one (or at least forget about it) and grab
the source tars from any ftp server and begin recompiling all the
packages you used (kernel, lilo, sysvinit, bash, libc, ncurses,
getty, login program, shadow password suite, sh-utils and util-linux
etc. etc. - it's the hell of a job.)
If you got that far (or perhaps earlier) you should perhaps lurk on
a debian development list to get a picture what the maintaining of a
complete distribution looks like.
--
Greets from over there
Dagurashibanipal
[EMAIL PROTECTED]
'What with our wounded who can't walk? We don't leave our own!'
'You're right, Captain. We'll take them. They're field rations'
-- Mary Gentle, 'Grunts!'
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: sleep_on
Date: 23 Mar 1999 19:14:16 -0500
In article <[EMAIL PROTECTED]>,
Wlmet <[EMAIL PROTECTED]> wrote:
>Doesn't the timer interrupt call schedule() regularly. What if it calls
No.
>schedule() right after this process changes its state? It seems to me that it
>will get stuck there if its new state is not interruptible.
Look: the fundamental thing about UNIX execution model being that there
are 3 states - user, upper-half and bottom-half. Interrupts move you to
bottom-half state. System calls - to upper-half. Both upper- and bottom-halves
are running in kernel mode. Bottom-halves do not have a context. Period.
They are asynchronous and may happen at any moment. Upper-half has a context -
context of calling process. Bottom-halves are not permitted to do a
context-switch. Typical situations look so:
a)
Process is running in user mode.
Interrupt happens.
Bottom half is called.
On return to user mode glue code in entry.S checks whether we need
to call schedule().
b)
Process is running in user mode.
Process makes a system call.
Process is running in upper-half.
Interrupt happens.
Bottom-half is called.
We return to the upper-half code.
We finish with syscall and return to user mode.
Glue code checks whether we need to call schedule().
c)
Process is running in user mode.
Process makes a system call.
We are in upper-half.
We *voluntary* call schedule().
Timer bottom-half doesn't call schedule() itself. Instead it sets
current->need_resched. Which is checked upon the return to user mode.
It's a *very* basic premise - upper-half code can't give up the
control unless it willingly does so. Otherwise race prevention would be
a nightmare. Bottom-half can interrupt the upper-half, but it always returns
and never blocks. Moreover, you can disable bottom-halves for a while
(doing it for a long time is *bad* idea, since you are going to lose the
network/disk/keyboard/mouse/whatever traffic).
Very roughly speaking, upper-half == system calls and everything they
directly call while the bottom-halves == drivers.
>Obviously, it doesn;t because the code works but I am missing something.
Take a look at arch/<foo>/kernel/entry.S and grep for involved
functions. For Linux-oriented description see TLK (on sunsite, in
/pub/Linux/docs/LDP/the-linux-kernel/). It's oriented towards data
structures. For more ideology-oriented stuff see the Daemon Book (4.4BSD
Design and Implementation), it covers generic UNIX kernel stuff very
well. You'll have to make some adjustments since it describes a different
kernel, but in combination with TLK and actual sources it's the best thing
I can think of. It's a must-have if you are playing with the kernel.
Kernel described in Daemon book can be found (modulo changes over the last
years) in *BSD. In many respects it's different from Linux, but this stuff
is *really* common for all Unices. Heck, if you'll dig out the Lions' Book
(v6 source circa 1975 + detailed comments) you'll see the same picture.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: comp.unix.programmer
Subject: Re: Fast IPC (low-latency for small messages)
Date: 23 Mar 1999 21:21:08 -0600
In article <[EMAIL PROTECTED]>,
G. Sumner Hayes <[EMAIL PROTECTED]> wrote:
>
>I'm interested in fast message-passing on Linux, especially in
>latency (I anticipate many small messages). I've been comparing a
>number of methods of IPC; unfortunately, the fastest are either
>insecure (SysV IPC) or don't scale to communications between more than
>two processes very easily. My efforts with the normal IPC mechanisms
>are after the question.
>
>Question: What's the best way to do fast IPC if I anticipate
>(relatively) long periods of time with no messages received interrupted
>by brief flurries of hundreds of messages going back and forth
>immediately? The application is structured as a server and anywhere
>from 1-many clients, most likely 4-10 clients; the clients aren't
>spawned by the server and no parent-child relationships should be
>assumed. Initial time to connect to the server and set up
>communications pathways is relatively unimportant. A message sent from
>one client to another may result in hundreds (or thousands) of messages
>being sent back and forth between the clients, each one going from
>sending client->server->receiving client.
On the local machine I would expect named pipes to perform
well where a reasonably small number of processes are involved
especially if the server has nothing to do but read messages
from a single stream, letting the kernel multiplex them in
FIFO order for you. You do have to keep track of the writer's
identity and message boundaries 'in-band', but this can be as
simple as using fixed length messages with the client pid
included. In trade you can reduce system calls by having the
server perform large reads to get all pending messages at once.
Each client would need it's own named pipe for communication
in the reverse direction.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
Date: Wed, 10 Mar 1999 15:52:53 +0100
From: Tony Scholes <[EMAIL PROTECTED]>
Subject: Source for SYSV 'banner'
Hi
Anyone know where I can lay my hands on the source of a SYSV 'banner'
program... You know the one that produces output like this :-
##### # ####
# # # # #
##### # #
# # # # ###
# # # # #
##### # ####
#### ##### # # ###### ######
# # # # # #
#### # # # ##### #####
# # # # # #
# # # # # # #
#### # #### # #
Ta
--
Tony Scholes
Technical Manager
===============================================================================
Beacon Computer Services Tel: +44 (0)1582 478888
The Friars, 82 High Street South Fax: +44 (0)1582 478810
Dunstable, Beds. UK Email: [EMAIL PROTECTED]
LU6 3HD Compuserve: 72660,207
===============================================================================
------------------------------
From: Thomas Zajic <[EMAIL PROTECTED]>
Subject: Re: Where should I look for the source for 'cp'?
Date: Wed, 24 Mar 1999 00:57:20 GMT
Bill Anderson wrote:
> Wlmet wrote:
> > >>Wise ones,
> > >>
> > >>I don't know where to find the source for the 'cp' command.
> > >>Is it supposed to be part of the shells?
> > >>I installed (via RedHat's RPM) the source for bash, but I cannot
> > >>find the relevant code.
> > >(in bash)
> > >$ rpm -qf $(which cp)
> > >fileutils-3.16-10
> > >fileutils is what you want. It is a gnu package available
> > >at ftp.gnu.org
> > Is there a similar command using Slackware?
TK212017089010:~$ grep -w cp /var/log/packages/*
/var/log/packages/bin:usr/man/man1/cp.1.gz
/var/log/packages/bin:bin/cp
> the above command utilizes the RedHat Package Manager. You *could* get
> it on your slackware box, but it is no there by default.
For a good reason, I might add - you donīt want it to be there. If
I would like to spend (read: waste) most of my time using Linux with
getting rid of dependency failures, Iīd go with Red Hat in the first
place.
> If you are not using rpm, the above command is unavailable, and
> useless anyway ;-)
As is rpm itself. ;-)
Thomas (Linux is Linux, but only Slackware is Slackware!)
--
=---------------------------------------------------------------------=
- Thomas Zajic aka ZlatkO ThE GoDFatheR, Vienna/Austria -
- Spam-proof e-mail: thomas(DOT)zajic(AT)teleweb(DOT)at -
=---------------------------------------------------------------------=
------------------------------
From: Thomas Zajic <[EMAIL PROTECTED]>
Subject: Re: Where should I look for the source for 'cp'?
Date: Wed, 24 Mar 1999 01:05:03 GMT
Thomas Zajic wrote:
> > > Is there a similar command using Slackware?
> TK212017089010:~$ grep -w cp /var/log/packages/*
> /var/log/packages/bin:usr/man/man1/cp.1.gz
> /var/log/packages/bin:bin/cp
> [ ... ]
Grrrr, hit "Send" too early ...
TK212017089010:~$ grep -wh "bin:" /var/log/packages/*
bin: Binaries that go in /bin and /usr/bin.
bin:
bin: System utilities and programs, such as GNU fileutils 3.12,
bin: elvis 1.8pl3, at-2.9b, Dillon's crond 2.2, file-3.22,
bin: GNU gawk 3.0.3, man-1.4i, modules-2.0.0, patch 2.1b, sed 2.05,
bin: sharutils-4.1, time-1.7, splitvt-1.6.3, tput-1.0, unarj-230,
bin: hdparm-3.3, color-ls-3.12.0.3, and zoo-2.10.
bin:
There, thatīs it. Now "Send" ... :-)
Thomas
--
=---------------------------------------------------------------------=
- Thomas Zajic aka ZlatkO ThE GoDFatheR, Vienna/Austria -
- Spam-proof e-mail: thomas(DOT)zajic(AT)teleweb(DOT)at -
=---------------------------------------------------------------------=
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: Where should I look for the source for 'cp'?
Date: 23 Mar 1999 17:37:26 -0800
Thomas Zajic <[EMAIL PROTECTED]> writes:
>> the above command utilizes the RedHat Package Manager. You *could* get
>> it on your slackware box, but it is no there by default.
>
>For a good reason, I might add - you donīt want it to be there. If
>I would like to spend (read: waste) most of my time using Linux with
>getting rid of dependency failures, Iīd go with Red Hat in the first
>place.
>
>> If you are not using rpm, the above command is unavailable, and
>> useless anyway ;-)
>
>As is rpm itself. ;-)
>
>Thomas (Linux is Linux, but only Slackware is Slackware!)
I must admit, there is an element of truth and wisdom in
that. I can give several examples of ways in which RPM could
be improved from recent experience. However, I do not feel
slackware is the cure - it is like ignoring the problem in
the first place.
1st example. Compile GTK-1.2 in /usr/local/ Try to install ANY GNOME
binary rpm, and it will tell you of failed dependencies. However, all
the files are there !!! They are just in /usr/local/lib instead of
/usr/lib. If installed with rpm --nodeps, and /sbin/ldconfig if run,
everything works fine.
2nd example. Some wise guy decided to start compiling the GNOME
packages with glibc2.1. Now, the GNOME packages will install just
fine, since /lib/libc.so.6 is still there, but it never does a
sanity check on libc. Then when you run practically any package,
you get a " Symbol not found __register_frame_info". Some wise
guy who made glibc2.1 moved the __register_frame_info from
libstdc++.so to libc.so.6.
HOW TO IMPROVE RPM management.
It seems like a wiser choice would be to have the binary rpm
contain a simple list of all the symbols the libraries depend
on as shared object files, and the ldd output for each, and then
do an nm check on the object files on the system as found by
ldconfig. It would be bombproof, and on failure could tell you
EXACTLY which shared object file failed and on what symbol.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Network protocol layer in Linux ?
Date: Thu, 11 Mar 1999 16:18:32 GMT
Is it possible to insert your own network protocol layer
(just above the NIC driver) in TCP/IP stack as it is possible
with STREAMS in solaris.
Neeraj
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Conrad Sanderson)
Subject: meteor module doesn't want to unload
Date: 24 Mar 1999 01:45:52 GMT
I have a problem with the meteor driver module refusing
to be unloaded - it's use count stays at 1, even when the
application that needed it has finished.
The next time the application starts up, it cannot open
the meteor device because the "device or resource is busy".
Attempts to forcefully remove the meteor module with rmmod
result in the same error - but nothing is using the module!
The only way to solve this is to reboot the machine.
The driver is available at
ftp://ftp.rwii.com/pub/linux/system/Meteor/meteor-1.5.3.tar.gz
I'm using the 2.2.3 kernel.
I've looked through the source code of the driver, and it seems
that MOD_DEC_USE_COUNT is never reached, which is in meteor_close(),
which in turn is called from a file_operations struct, presumably
by the kernel.
Looking through the debugging output in /var/log/messages,
it seems that only meteor_mmap() is called during exit.
I don't have much experience with Linux internals, and I don't
know which way to proceed. Any pointers would be greatly
appreciated.
--
Conrad Sanderson - Microelectronic Signal Processing Laboratory
Griffith University, Queensland, Australia
------------------------------
From: Thomas Zajic <[EMAIL PROTECTED]>
Subject: Re: Where should I look for the source for 'cp'?
Date: Wed, 24 Mar 1999 05:03:41 GMT
David T. Blake wrote:
> I must admit, there is an element of truth and wisdom in
> that. I can give several examples of ways in which RPM could
> be improved from recent experience. However, I do not feel
> slackware is the cure - it is like ignoring the problem in
> the first place. ^^^^^^^^^^^^^^^^^^^^
Letīs put it that way - Slackware is not the _only_ cure. You
might as well run a Red Hat System without ever touching rpm
again after the initial install. But I strongly beg to differ
concerning your "using Slackware is like ignoring the problem"
statement. Rather, Slackware assumes that the user knows what
heīs doing (a dangerous assumption, I know ;-), and tries not
to get in the way.
> 1st example. Compile GTK-1.2 in /usr/local/ Try to install ANY GNOME
> binary rpm, and it will tell you of failed dependencies. However, all
> the files are there !!! They are just in /usr/local/lib instead of
> /usr/lib. If installed with rpm --nodeps, and /sbin/ldconfig if run,
> everything works fine.
Well then, whereīs the difference between īrpm --nodepsī and
ītar -xzfvī? ;-) Itīs even easier if Iīm compiling some apps
myself - I _know_ that I installed the necessary libs, and I
know _where_ I did install them. And I just edit my Makefile
accordingly, or better yet, have ./configure figure it out
by itself. And I definitely donīt need some smartass package
manager telling me I canīt do that when I very well know that
I can ...
> 2nd example. Some wise guy decided to start compiling the GNOME
> packages with glibc2.1. Now, the GNOME packages will install just
> fine, since /lib/libc.so.6 is still there, but it never does a
> sanity check on libc. Then when you run practically any package,
> you get a " Symbol not found __register_frame_info". Some wise
> guy who made glibc2.1 moved the __register_frame_info from
> libstdc++.so to libc.so.6.
This is not a Red Hat/Slackware/whatever specific problem,
but a problem of installing pre-built binaries instead of
compiling the source yourself. And this doesnīt only happen
with significantly different library versions like libc5 vs.
libc6/glibc2 or glibc2 vs. glibc2.1, it can also happen with
minor differences like libc5.4.46 vs. libc5.4.38.
Add to that some X or GUI stuff that was compiled into the
binary with different versions than the one on your system,
and chances are it wonīt work. Qt, gtk+, LessTif, GNOME,
X in general, it happens all the time. Personally, I compile
all the stuff myself whenever possible.
> HOW TO IMPROVE RPM management.
> It seems like a wiser choice would be to have the binary rpm
> contain a simple list of all the symbols the libraries depend
> on as shared object files, and the ldd output for each, and then
> do an nm check on the object files on the system as found by
> ldconfig. It would be bombproof, and on failure could tell you
> EXACTLY which shared object file failed and on what symbol.
A step in the right direction ... :-)
Thomas
--
=---------------------------------------------------------------------=
- Thomas Zajic aka ZlatkO ThE GoDFatheR, Vienna/Austria -
- Spam-proof e-mail: thomas(DOT)zajic(AT)teleweb(DOT)at -
=---------------------------------------------------------------------=
------------------------------
** 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
******************************
