Linux-Development-Sys Digest #804, Volume #7 Wed, 26 Apr 00 14:15:40 EDT
Contents:
Re: How legal is it??? (Jim Hyslop)
Re: cli() & sti()... (Kaz Kylheku)
Re: cli() & sti()... (Kaz Kylheku)
Re: cli() & sti()... (Kaz Kylheku)
Re: getting started... ("Clint Box")
Re: modules not working after kernel compile (David T. Blake)
Calc number of pending bytes on a socket... ([EMAIL PROTECTED])
Re: Glibc2 install. Oh boy... (Andreas Jaeger)
Calc number of pending bytes on a socket... ([EMAIL PROTECTED])
Re: cli() & sti()... (Bill Waddington)
Re: Allocating memory at a specific physical locaation (Marc SCHAEFER)
Re: Calc number of pending bytes on a socket... (Kaz Kylheku)
Re: cli() & sti()... (Kaz Kylheku)
Re: modules not working after kernel compile (Kaz Kylheku)
Time for the MS-rats to desert (John Unekis)
----------------------------------------------------------------------------
From: Jim Hyslop <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++,comp.os.linux.development.apps
Subject: Re: How legal is it???
Date: Wed, 26 Apr 2000 15:36:58 GMT
In article <[EMAIL PROTECTED]>,
_Steven Chang <[EMAIL PROTECTED]> wrote:
> When you said the "Corps" and the "Big Brother", who are they?
Not sure about the "Corps" but "Big Brother" is a reference to George
Orwell's book "1984" (written many years earlier) in which the
government was referred to as "Big Brother" and monitored everything you
did and thought. The slogan "Big Brother is watching!" was prominent.
> Thanks!
> Steven
>
> Blue Shadow wrote:
> >
> > It is very legal. The corps have been doing it for years. It's
> > called 'productivity software'. It's a legal way to spy on your
> > employees. Now, in a more mainstream aspect, as long as your
'target'
> > gives you the ok to run this little app, no problem. If they don't,
then
> > you could get into some problems. As for the privacy issue, it
violates
> > every point of that, but hey! As long as Big Brother and the Corps
are
> > doing it, why can't you? If you can write it, and package it
without
> > letting the LUser know about it, then what's the worry?
> >
> > Under Linux it's OK, but harder, as you may run into firewalls, and
other
> > server side issues.
> >
> > Under Win 9x you may get into problems with Micro$oft, but who
doesn't.
> > If you even look at the licensing agreement wrong you violate it.
"Click
> > yes to sign over you firstborn, or else the program will not work!"
> > Micro$oft sucks.
--
Jim
I ignore all email from recruitment agencies. Except that
I reserve the right to send rude, nasty replies to recruiters.
Please do not send me email with questions - post
here.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: cli() & sti()...
Reply-To: [EMAIL PROTECTED]
Date: Wed, 26 Apr 2000 15:53:30 GMT
On 26 Apr 2000 07:15:08 GMT, Villy Kruse <[EMAIL PROTECTED]>
wrote:
>On Mon, 17 Apr 2000 01:50:38 GMT,
> Johan Kullstam <[EMAIL PROTECTED]> wrote:
>
>
>
>>Badrinath Venkatachari <[EMAIL PROTECTED]> writes:
>>
>>> Hi,
>>> If I happen to have this pair cli() to disable interrupts and sti() to
>>> enable interrupts, then can it be assumed that the process cannot be
>>> preempted while executing code in between them ???
>>>
>>> cli()
>>>
>>> /* code comes here */
>>>
>>> sti()
>>
>>make sure you consider SMP too.
>>
>
>
>
>Exactly. For a multiprocessor system you need a spinlock in addition to
>masking the interrupt to truely protect that piece of code from being
>re-entetered by the other processor getting an interrupt. Masking an
True, but wrong in the context of a discussion about Linux cli() and sti().
These functions no longer mean ``disable interrupts on the local processor''.
Instead they are a backwards compatibility kludge to create a sort of critical
region across all the processors---with some exceptions, I believe. I think
that when an ISR calls cli() on one processor, interrupts can still happen on
another, the idea being that these interrupts are unrelated to the ISR. Or
something like that; I don't remember the details and they are not really
important, because one should avoid using cli() and sti() in new Linux kernel
programming.
The spin_lock_irqsave() function masks local interrupts and does the spin; it
should be used instead.
>interrupt only works on the current processor and has no effect on any
>of the other processors.
The functions for manipulating local interrupts are now called __cli(),
__sti() __save_flags() and __restore_flags()
Of course, on a single processor kernel, cli() and sti() do collapse into their
old role. As well, spin_lock_irqsave() just performs a save_flags(); cli()
sequence on a single processor.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: cli() & sti()...
Reply-To: [EMAIL PROTECTED]
Date: Wed, 26 Apr 2000 16:02:50 GMT
On Wed, 26 Apr 2000 13:53:37 GMT, ���ظ� Chun-Mok Chung <[EMAIL PROTECTED]>
wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> On Sun, 16 Apr 2000 19:38:20 -0700, Badrinath Venkatachari <[EMAIL PROTECTED]>
>>
>> What happens is that cli() and sti() are emulated in a bletcherous way on SMP.
>> The point I'm trying to get to is that cli() and sti() are obsolete, legacy
>> operations---do not use them! Use spinlocks. The operations spin_lock_irqsave()
>> and spin_unlock_irqrestore() work correclty under SMP and on a uP kernel they
>> collapse into save_flags(); cli() and restore_flags().
>>
>
>I cannot find spin_lock_xxx() functions. I can only find spinlock() and
>spinunlock() at <asm/locks.h>. I use kernel 2.0.36 with x86 mpu. Where can I
>find your saying functions?
These functions are not in the outdated 2.0 kernel. They were introduced
in 2.1. On a 2.0 kernel, you should use save_flags(); sti() ... restore_flags()
or cli() and sti(). Or else make macros that make these look like the spinlock
functions.
What I did in the mobitex radio modem driver is simply create lock and unlock
methods on the driver object. These are implemented differently for 2.0 and
2.2. I used a separate CVS branch for both kernels, though #ifdefs can
obviously be used as well.
Here is what the 2.0 code looks like:
static void masc_lock(masc_dev_t *masc)
{
long flags;
save_flags(flags);
cli();
masc->flags = flags;
}
static void masc_unlock(masc_dev_t *masc)
{
long flags = masc->flags;
restore_flags(flags);
}
And the 2.2 equivalent, where the masc->spinlock is of type spinlock_t.
static void masc_lock(masc_dev_t *masc)
{
long flags;
spin_lock_irqsave(&masc->spinlock, flags);
masc->flags = flags;
}
static void masc_unlock(masc_dev_t *masc)
{
long flags = masc->flags;
spin_unlock_irqrestore(&masc->spinlock, flags);
}
Note that the flags must always be a local variable. Only once you have the
critical region can you save this to a shared place. Otherwise you have a race
condition: your flags could be clobbered between the time you save them and
actually acquire the lock.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: cli() & sti()...
Reply-To: [EMAIL PROTECTED]
Date: Wed, 26 Apr 2000 16:04:12 GMT
On Wed, 26 Apr 2000 14:15:34 GMT, Bill Waddington
<[EMAIL PROTECTED]> wrote:
>
>
>> The point I'm trying to get to is that cli() and sti() are obsolete,
>legacy
>> operations---do not use them! Use spinlocks. The operations
>spin_lock_irqsave()
>> and spin_unlock_irqrestore() work correclty under SMP and on a uP
>kernel they
>> collapse into save_flags(); cli() and restore_flags().
>
>Hello,
>
>When using the above, does one place similar spinlocks in the interrupt
>code?
Yes.
--
#exclude <windows.h>
------------------------------
From: "Clint Box" <[EMAIL PROTECTED]>
Subject: Re: getting started...
Date: Wed, 26 Apr 2000 16:10:31 GMT
Thanks.... I'll see if I can't find a copy.
Clint
"Pankaj Chhabra" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi,
>
> Here is a good book on OS -
> Operating System Concepts, 5th Edition
> by Abraham Silberschatz, Peter Baer Galvin
>
> Next level is this book -
> Operating Systems: Internals and Design Principles -- William
Stallings;
>
>
>
> - Pankaj
>
>
> Clint Box wrote:
>
> > Hey,
> >
> > I've purchased "Design and Implementation of 4.4BSD" and it's not a
starter
> > book. It's very informative but I think I need to get a better
understand
> > of OS functions. Can anyone suggest a good book, or video, or even a
simple
> > OS that would simplify what an OS can and should do?
> >
> > Clint
>
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: modules not working after kernel compile
Date: 26 Apr 2000 15:27:20 GMT
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Try this (assuming same kernel *version*, just different mod setup):
>
> make modules
> mv /lib/modules/<version> /lib/modules/<version>.old
> make modules_install
>
> Reboot! (for depmod to work)
> Reboot again!
You are crazy. To only change modules, do
make modules
mv /lib/modules/<version> /lib/modules/<version>.old
make modules_install
depmod -a
Then the modules should be accessible. Rebooting is
ONLY necessary if you wish to change the running
kernel, or reset it in some way.
If you additionally have a new kernel, you only need
reboot once, and then make certain depmod has run (there
will be a dependency file in /lib/modules/`uname -r`/
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,comp.os.linux
Subject: Calc number of pending bytes on a socket...
Date: Wed, 26 Apr 2000 16:44:57 GMT
hey all,
How does one calculate the number of bytes to read of a received packet
on Linux? On Solaris, I would do it this way:
int pkt_len;
ioctl(sockno, I_NREAD, &pkt_len);
Any assistance would be greatly appreciated!
tia,
robert
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: Glibc2 install. Oh boy...
Date: 26 Apr 2000 18:41:24 +0200
>>>>> mcnuttj writes:
> Okay, does that mean I can remove all of /usr/i586-pc-linux-gnulibc1/?
> That's where the old _G_config.h file was.
In that case your gcc installation is broken. gcc shouldn't search
that directory.
Andreas
> --J
> P.S. Thanks much! I hate missing stuff in the FAQ.... <grr...>
> Andreas Jaeger <[EMAIL PROTECTED]> wrote:
> :>>>>> mcnuttj writes:
> : > Okay, now I'm in big trouble.
> : > I got glibc-2.1.3 to compile. I got it to 'make check' successfully. I
> : > moved all my old libs and my old *.o and old symlinks. I even edited
> : > my specs file.
> : > 'make install' in the target glibc directory gives me the following:
> : > CC="gcc" /usr/bin/perl scripts/test-installation.pl /usr/src/glibc-target/
> : > In file included from /usr/include/stdio.h:57,
> : > from /tmp/test-prg8281.c:2:
> : > /usr/include/libio.h:370: parse error before `_IO_seekoff'
> : > /usr/include/libio.h:370: parse error before `_G_off64_t'
> : > /usr/include/libio.h:371: parse error before `_IO_seekpos'
> : > /usr/include/libio.h:371: parse error before `_G_fpos64_t'
> : > Execution of GCC failed!
> : > ...and then it gives me some suggestions on how to fix it. I'm pretty sure
> : > it isn't the specs file, and I'm pretty sure it isn't a symlink thing (the
> : > two suggestions listed by 'make').
> : > Any ideas? My system still seems to work, since I moved all by old libs
> : > properly, but I can't compile anything until this is fixed, and I need
> : > libc.so.6 for several programs I want to run.
> : Read the FAQ:
> : 2.29. Compiling programs I get parse errors in libio.h (e.g. "parse error
> : before `_IO_seekoff'"). How should I fix this?
> : Andreas
> : --
> : Andreas Jaeger
> : SuSE Labs [EMAIL PROTECTED]
> : private [EMAIL PROTECTED]
--
Andreas Jaeger
SuSE Labs [EMAIL PROTECTED]
private [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Calc number of pending bytes on a socket...
Date: Wed, 26 Apr 2000 16:45:57 GMT
hey all,
How does one calculate the number of bytes to read of a received packet
on Linux? On Solaris, I would do it this way:
int pkt_len;
ioctl(sockno, I_NREAD, &pkt_len);
Any assistance would be greatly appreciated!
tia,
robert
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bill Waddington <[EMAIL PROTECTED]>
Subject: Re: cli() & sti()...
Date: Wed, 26 Apr 2000 16:50:21 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Wed, 26 Apr 2000 14:15:34 GMT, Bill Waddington
> <[EMAIL PROTECTED]> wrote:
> >
> >
> >> The point I'm trying to get to is that cli() and sti() are
obsolete,
> >legacy
> >> operations---do not use them! Use spinlocks. The operations
> >spin_lock_irqsave()
> >> and spin_unlock_irqrestore() work correclty under SMP and on a uP
> >kernel they
> >> collapse into save_flags(); cli() and restore_flags().
> >
> >Hello,
> >
> >When using the above, does one place similar spinlocks in the
interrupt
> >code?
>
> Yes.
>
> --
> #exclude <windows.h>
>
Thanks,
Sorry to be such a blockhead ... are the lock and unlock ops used in the
interrupt code spin_lock_irqsave()and spin_unlock_irqrestore() or
some related lock and unlock ops? (& if so, what are they, please)
Do I understand correctly from the previous discussion that cli()/sti()
still function on SMP hardware, but at the expense of locking out
interrupts across all processors?
Thanks again,
Bill
--
Bill Waddington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Marc SCHAEFER <[EMAIL PROTECTED]>
Subject: Re: Allocating memory at a specific physical locaation
Date: 26 Apr 2000 09:12:53 GMT
Timur Tabi <[EMAIL PROTECTED]> wrote:
: I'm writing a device driver that needs to be able to allocate a chunk
: of physical
General answer:
open /dev/mem
mmap
: physical block, the kernel will need to copy the data to some other
: physical memory block, and remap the virtual area to the new block, and
: then let me have the physical block.
No. However, you can allocate physical memory in your driver (using
kmalloc()), and map it to user space (notably the sound card does that).
: In addition, I need to be able to alter the "cacheability" of the memory
: block. For these blocks, caching needs to be disabled, and
: write-combining needs to be turned on.
hum, this might need to tell the VM subsystem to not use that block
at all.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Calc number of pending bytes on a socket...
Reply-To: [EMAIL PROTECTED]
Date: Wed, 26 Apr 2000 17:10:35 GMT
On Wed, 26 Apr 2000 16:45:57 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>hey all,
>
> How does one calculate the number of bytes to read of a received packet
>on Linux? On Solaris, I would do it this way:
>
> int pkt_len;
> ioctl(sockno, I_NREAD, &pkt_len);
>
> Any assistance would be greatly appreciated!
It looks like the TIOCINQ ioctl puts the size of a pending packet into an int
argument. If there is no pending packet, a zero is stored.
Use the source, Luke!
The following appears in net/ipv4/udp.c :
/*
* IOCTL requests applicable to the UDP protocol
*/
int udp_ioctl(struct sock *sk, int cmd, unsigned long arg)
{
switch(cmd)
{
case TIOCOUTQ:
{
unsigned long amount;
amount = sock_wspace(sk);
return put_user(amount, (int *)arg);
}
case TIOCINQ:
{
struct sk_buff *skb;
unsigned long amount;
amount = 0;
/* N.B. Is this interrupt safe??
-> Yes. Interrupts do not remove skbs. --ANK (980725)
*/
skb = skb_peek(&sk->receive_queue);
if (skb != NULL) {
/*
* We will only return the amount
* of this packet since that is all
* that will be read.
*/
amount = skb->len - sizeof(struct udphdr);
}
return put_user(amount, (int *)arg);
}
default:
return(-ENOIOCTLCMD);
}
return(0);
}
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: cli() & sti()...
Reply-To: [EMAIL PROTECTED]
Date: Wed, 26 Apr 2000 17:23:54 GMT
On Wed, 26 Apr 2000 16:50:21 GMT, Bill Waddington
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> On Wed, 26 Apr 2000 14:15:34 GMT, Bill Waddington
>> <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> >> The point I'm trying to get to is that cli() and sti() are
>obsolete,
>> >legacy
>> >> operations---do not use them! Use spinlocks. The operations
>> >spin_lock_irqsave()
>> >> and spin_unlock_irqrestore() work correclty under SMP and on a uP
>> >kernel they
>> >> collapse into save_flags(); cli() and restore_flags().
>> >
>> >Hello,
>> >
>> >When using the above, does one place similar spinlocks in the
>interrupt
>> >code?
>>
>> Yes.
>>
>> --
>> #exclude <windows.h>
>>
>
>Thanks,
>
>Sorry to be such a blockhead ... are the lock and unlock ops used in the
>interrupt code spin_lock_irqsave()and spin_unlock_irqrestore() or
>some related lock and unlock ops? (& if so, what are they, please)
No, you spin_lock_irqsave() in interrupt code as well. Here
are some rules of thumb: if you know that you are running in a context
that has interrupts enabled you can use spin_lock_irq() and
spin_unlock_irq(). These functions don't bother saving and restoring
flags. If you don't know whether interrupts are masked or unmasked
on the local processor, then use spin_lock_irqsave() and
spin_unlock_irqrestore().
In other words, in places where you would use cli() and sti() on 2.0 or older
kernels, you can use spin_lock_irq() and spin_unlock_irq(). In places where
you would have used save_flags(flags); cli(); and restore_flags(), you now use
spin_lock_irqsave() and spin_unlock_irqrestore().
Avoid using spin_lock and spin_unlock since they don't do anything with
interrupts. They can't protect processes from ISR's. What they can
do is protect critical regions against concurrent access by processes,
as long as those region is not executed by interrupt code.
You must not reschedule while holding a spin lock, otherwise some process will
come along and try to acquire the lock which is held by the suspended process.
By doing so, it hog the CPU and prevent the suspended process from releasing
the lock. If you need long locks among processes, use semaphores.
>Do I understand correctly from the previous discussion that cli()/sti()
>still function on SMP hardware, but at the expense of locking out
>interrupts across all processors?
Sort of. It's pretty bletcherous; to understand it fully, you have to
follow the source code, of course. There are some concessions made;
it's not a full lockout just a reasonable lockout.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: modules not working after kernel compile
Reply-To: [EMAIL PROTECTED]
Date: Wed, 26 Apr 2000 17:25:28 GMT
On 26 Apr 2000 15:27:20 GMT, David T. Blake <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Try this (assuming same kernel *version*, just different mod setup):
>>
>> make modules
>> mv /lib/modules/<version> /lib/modules/<version>.old
>> make modules_install
>>
>> Reboot! (for depmod to work)
>> Reboot again!
>
>You are crazy.
No, maybe he is just a Windows NT user who has not been fuly rehabilitated.
Say, Andreas, when are we getting a RenameFileEx function in glibc? ;)
--
#exclude <windows.h>
------------------------------
From: John Unekis <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.advocacy,comp.os.ms-windows.advocacy,comp.os.ms-windows.nt.advocacy,comp.os.linux.networking,comp.os.linux.security,comp.os.ms-windows.networking.tcp-ip,alt.conspiracy.area51
Subject: Time for the MS-rats to desert
Date: Wed, 26 Apr 2000 12:52:00 -0400
There is an old joke about a hooker who goes into a bar, orders a drink, and pays
with a 20-dollar bill.
The bartender holds the 20 up to the light and remarks - "Hey, you can't use
this, this $20 is counterfeit!"
To which the hooker exclaims - "Oh, no, I've been raped!"
Now that Microsoft stock is in free-fall, quickly heading for under $50/share,
there must be a lot
of Code-Ho's up in Redmond who have sold their souls to Bill for stock options,
dreaming of
retiring young and rich, who are now realizing they've been raped.
I noticed that Microsoft is reimbursing its senior managers for their stock
losses with new stock options which
are adjusted for the lower share price.
For regular employees, MS is encouraging them to take a "long term view".
The only thing long-term at Microsoft is the duration of the screwing that
employees are getting.
I imagine that it is going to become very difficult to find u-haul trailers in
the Redmond area as more and more victims of the "Cult of Bill" awaken from their
trances and decide to show Microsoft a long-term view of their ass.
Remember all you Microserfs, the ones who bail first will get all the good jobs
down in Silicon valley, the stragglers will end up fetching them coffee....
------------------------------
** 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
******************************
