Linux-Development-Sys Digest #141, Volume #8 Tue, 12 Sep 00 19:13:16 EDT
Contents:
creating a bootable redhat install CD ([EMAIL PROTECTED])
snmp on eth0 shows zero packets ([EMAIL PROTECTED])
memory stomp using AF_PACKET socket ("Dave Rhodes")
docs on message queues and events (Tom Oswald)
Atomic functions and user mode ("Brice Breeden")
Critical sections and spinlocks in Linux ("Brice Breeden")
Re: Atomic functions and user mode (Kaz Kylheku)
scheduling under Linux not suitable for interactive work? ([EMAIL PROTECTED])
Re: Newbie question on programming? (Karl Heyes)
Re: Critical sections and spinlocks in Linux (Kaz Kylheku)
Re: Wish for a writable ISO-9660 compatible filsystem (Jerry Peters)
Re: scheduling under Linux not suitable for interactive work? (Kaz Kylheku)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: creating a bootable redhat install CD
Date: Tue, 12 Sep 2000 21:04:13 GMT
Please CC my email with any reply... [EMAIL PROTECTED]
I usually purchase a redhat package, and I like having the bootable CD.
One time however, it was late, and I need the latest release and
couldn't wait for next day delivery.
I downloaded the distribution and burned it to CD but the install would
fail somewhere during the boot process.
It has been a while since I did this, but I remember that a mount
command showed my burned CD as being mounted "read only"
When I mount an official Redhat CD, the perms show "owner rw" perms on
the root and all files.
It makes sense to me that the boot CD needs to fool the system into
believing the filesystem is read/write, when actually it is read only,
for the limited use that the installation requires.
I looked at the mkisofs src and the cdrecord src and I cannot see where
I could possibly force the perms on the CD to be anything but read only.
Does anyone know what the trick is? Or am I way off base?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: snmp on eth0 shows zero packets
Date: Tue, 12 Sep 2000 21:11:34 GMT
I am monitoring packet traffic with MRTG. Excellent choice.
I have snmp setup on several boxes, and all is good.
One one box, I used to have two NIC cards. I removed one and re-
arranged the conf.modules and sysconfig definitions, and all is well.
Except that snmp is reporting zero octets for the interface now.
ifconfig shows the correct numbers, and the same version OS (rh 6.2)
works fine on some other boxes (that I did not remove a second nic card
from) just fine. But snmpwalk (and mrtg) show goose eggs.
interfaces.ifNumber.0 = 2
interfaces.ifTable.ifEntry.ifIndex.1 = 1
interfaces.ifTable.ifEntry.ifIndex.2 = 2
interfaces.ifTable.ifEntry.ifDescr.1 = lo0
interfaces.ifTable.ifEntry.ifDescr.2 = eth0
interfaces.ifTable.ifEntry.ifType.1 = softwareLoopback(24)
interfaces.ifTable.ifEntry.ifType.2 = ethernetCsmacd(6)
interfaces.ifTable.ifEntry.ifMtu.1 = 3924
interfaces.ifTable.ifEntry.ifMtu.2 = 1500
interfaces.ifTable.ifEntry.ifSpeed.1 = Gauge: 10000000
interfaces.ifTable.ifEntry.ifSpeed.2 = Gauge: 10000000
interfaces.ifTable.ifEntry.ifPhysAddress.1 =
interfaces.ifTable.ifEntry.ifPhysAddress.2 = <snip.snip>
interfaces.ifTable.ifEntry.ifAdminStatus.1 = up(1)
interfaces.ifTable.ifEntry.ifAdminStatus.2 = up(1)
interfaces.ifTable.ifEntry.ifOperStatus.1 = up(1)
interfaces.ifTable.ifEntry.ifOperStatus.2 = up(1)
interfaces.ifTable.ifEntry.ifInOctets.1 = 425894
interfaces.ifTable.ifEntry.ifInOctets.2 = 0
interfaces.ifTable.ifEntry.ifInUcastPkts.1 = 3545
interfaces.ifTable.ifEntry.ifInUcastPkts.2 = 11140
interfaces.ifTable.ifEntry.ifInErrors.1 = 0
interfaces.ifTable.ifEntry.ifInErrors.2 = 11
interfaces.ifTable.ifEntry.ifOutOctets.1 = 426876
interfaces.ifTable.ifEntry.ifOutOctets.2 = 0
interfaces.ifTable.ifEntry.ifOutUcastPkts.1 = 3557
interfaces.ifTable.ifEntry.ifOutUcastPkts.2 = 10605
interfaces.ifTable.ifEntry.ifOutDiscards.1 = 0
interfaces.ifTable.ifEntry.ifOutDiscards.2 = 0
interfaces.ifTable.ifEntry.ifOutErrors.1 = 0
interfaces.ifTable.ifEntry.ifOutErrors.2 = 0
interfaces.ifTable.ifEntry.ifOutQLen.1 = Gauge: 0
interfaces.ifTable.ifEntry.ifOutQLen.2 = Gauge: 0
Anybody seen this before?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Dave Rhodes" <[EMAIL PROTECTED]>
Subject: memory stomp using AF_PACKET socket
Date: Tue, 12 Sep 2000 17:56:33 -0400
I have been trying to (unsuccessfully) implement user level (server side)
TCP handling. I am
using ipchains to DENY the port that I am using for the server (selected
from an unused number
greater than 50000) to prevent the normal kernel handling from seeing
incoming packets and
am using AF_PACKET sockets to get underneath the kernel firewall -- this
seems to work
[thanks Andi K]. Although not shown in the snippet below, all errors are
checked, etc.
short snippet: (on kernel 2.2.14)
==================================
fd = socket(AF_PACKET, SOCK_DGRAM, htons(ETH_P_IP)); // ETH_P_ALL does same
...
struct sockaddr sa;
n_recv = recvfrom(fd, mes, mes_sz, 0, &sa, &sa_sz); // works fine, no
ll-header
// sa is in the link layer family:
struct sockaddr_ll *sa_ll = (struct sockaddr_ll *) &sa;
sa_ll.sll_pkttype = PACKET_OUTGOING; // flip the sock to outgoing
(necessary?)
// same problems even if you don't do this
// I have verified the sa struct, it is in right family, has ARPHDR_ETHER
for
// sll_hatype, etc. Do I have to do my own ARP here? I tried putting a perm.
// arp entry for the destination IP, makes no difference. What are the arp
requirements
// for using AF_PACKET, SOCK_DGRAM anyway?
// next form a IP/TCP packet in mes2 (this is correct afaik, and verified
several ways)
...
// send response back to the interface from which it came (makes sense ?):
n_sent = sendto(fd, mes2, mes2_sz, 0, &sa, sa_sz);
// sendto succeeds, it goes on the wire but the destination ethernet address
as
// viewed using ethereal is WRONG (and seems to be stomped, see below).
===================================
The last two bytes of the ethernet destination address are suspiciously
"45 00" which happen to be the first two bytes of the IP packet. The
beginning
bytes are the correct for the destination, however. Is the link-layer header
length
wrong? Ethereal (and tcpdump) show the IP packet as being correct. The same
code does not work through the 'lo' interface either (where the Ethernet II
frame
is shown with all 0's via Ethereal).
Am I doing something wrong with this? Do I need to ARP? Is there a kernel
upgrade that I am missing?
Any suggestions or ideas on what might be wrong, or alternative ways of
implementing
user level protocols, welcome!
thanks, dave
------------------------------
From: Tom Oswald <[EMAIL PROTECTED]>
Subject: docs on message queues and events
Date: Thu, 07 Sep 2000 15:00:24 -0700
We are moving existing code from a PSOS environment to run under a Linux
process, i.e., a PSOS task would be a linux pthread. Please tell me
where I might find documentation on POSIX type messaging queues and
events, not signals, notification for threads under Linux.
Thanks,
Tom
------------------------------
From: "Brice Breeden" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Atomic functions and user mode
Date: Tue, 12 Sep 2000 17:23:25 -0500
Windows has some Interlocked... functions in its
API, which support atomic operations.
I'm trying to see if Linux has similar functions
available in user mode. Could a Linux API similar
to:
tUInt32 AtomicIncrement32(tUInt32 *cell);
tUInt32 AtomicDecrement32(tUInt32 *cell);
void* AtomicCompareExchangePtr32(void **cell,
void *ExchangeVal,void *CompareVal);
tUInt32 AtomicExchangeAdd32(tUInt32 *cell,tUInt32 value);
void* AtomicExchangePtr32(void **cell,void *ExchangeVal);
NOTE: tUInt32 represents an unsigned 32-bit int.
Additional functions must be written for
64-bit platforms.
If there are no similar functions available,
who can I submit x86 assembler source to?
The glibc team?
That way, people can write portable code
without worrying about CPU (x86, sparc, others).
------------------------------
From: "Brice Breeden" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Critical sections and spinlocks in Linux
Date: Tue, 12 Sep 2000 17:27:56 -0500
I have a portable C++ multi-threading library for
Windows/Linux and I'm trying to find the
fastest possible mutual-exclusion API in
Linux from user mode. I'm assuming that the
increased efficiency implies that locks
are only performed within the same process.
Here are the two classes I'm using:
Mutex uses a pthreads mutex or a System V semaphore,
depending on whether it is shared between processes.
Spinlock is meant for use in a single process. Currently,
I'm using a pthreads mutex. I'd like to know if there's
a faster alternative on Linux from user mode. The reason
I'm asking is that Windows defines a mutex as well as
a critical section.
NOTE: The reason for having two classes is that the
Mutex has more features (such as timeouts).
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Atomic functions and user mode
Reply-To: [EMAIL PROTECTED]
Date: Tue, 12 Sep 2000 22:31:41 GMT
On Tue, 12 Sep 2000 17:23:25 -0500, Brice Breeden <[EMAIL PROTECTED]> wrote:
>Windows has some Interlocked... functions in its
>API, which support atomic operations.
>I'm trying to see if Linux has similar functions
>available in user mode. Could a Linux API similar
There are some functions in the <linux/atomic.h> kernel header that can be used
from user mode. The actual contents of this header vary from target hardware to
target hardware.
>to:
>
> tUInt32 AtomicIncrement32(tUInt32 *cell);
>
> tUInt32 AtomicDecrement32(tUInt32 *cell);
>
> void* AtomicCompareExchangePtr32(void **cell,
> void *ExchangeVal,void *CompareVal);
>
> tUInt32 AtomicExchangeAdd32(tUInt32 *cell,tUInt32 value);
>
> void* AtomicExchangePtr32(void **cell,void *ExchangeVal);
You will find that the equivalents for these functions are not available on
Win32 platforms. So you cannot say ``Windows has...'' without qualifying which
windows and what functions. Windows CE devices don't have
InterlockedCompareExchange. Windows 95 has InterlockedIncrement and
InterlockedDecrement with different semantics from Windows 95 or NT. Then
there are some new functions that are NT only.
>If there are no similar functions available,
>who can I submit x86 assembler source to?
>The glibc team?
My guess would be /dev/null
Glibc already has this type of code in it for internal use. It's likely that
the maintainers would not agree to have such functions exposed as public
library interfaces, and that they would have broad popular support in that
decision.
The problem is that only a limited subset of such functions could be
implemented on all the target hardware. What good is an interface that doesn't
work everywhere?
Any successful interface proposal will probably have to make provisions for
emulation. That is to say, the atomic type would be abstract, allowing it to be
implemented as a struct with extra fields in it to implement a lock on machines
that don't have the hardware. E.g.
typedef unsigned long atomic_t; /* if we have all the hardware */
typedef struct { /* if we don't have the hardware */
unsigned long __counter;
pthread_mutex_t __lock;
} atomic_t;
All the functions would operate on atomic_t's, not directly on types like
void * or unsigned long.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: [EMAIL PROTECTED]
Subject: scheduling under Linux not suitable for interactive work?
Date: 13 Sep 2000 09:36:57 +0000
Hello all!
I have recently experienced, not for the first time, a complete
choking of the system (Linux 2.2.14) when I ran an editting session
(emacs) at the same time as some compute intensive tasks. I did not
play with priorities or nice values. I was practically unable to edit,
it took tens of seconds for characters to appear, or mouse pointer to
move. On another occasion, I was editting a big file (~2Mb) and I ran
a text replacement command on the whole buffer. The system froze and I
couldn't do anything until the replacement command finished (after
couple of minutes).
I never studied the scheduling policy under Linux, I just assumed that
it dynamically adjusted process priorities to boost priorities of
processes that do not fully use their allocated CPU slice, while
lowering priorities of processes that make full or almost full use of
their CPU slice, thus preventing CPU-bound tasks from clogging the
system. Well, it doesn't seem to be happening on my system.
I currently run debian 2.2 with X, on a 686 200MHz 64Mb RAM PC. Has
anyone experienced anything similar, and can I change this behaviour
somehow by modifying some configuration files, or kernel setup?
Regards,
Milan
--
Pursuant to U.S. code,title 47, Chapter 5, Subchapter II, Section 227,
and consistent with Oregon State Law, any and all nonsolicited commercial
E-mail sent to this address is subject to a consulting fee of $500.00 U.S.
E-Mailing denotes acceptance of these terms.
Consult <http://www.law.cornell.edu/uscode/47/227.html> for details.
------------------------------
From: Karl Heyes <[EMAIL PROTECTED]>
Subject: Re: Newbie question on programming?
Date: Tue, 12 Sep 2000 23:48:39 +0000
In article <cLjv5.4707$[EMAIL PROTECTED]>, "eric07"
<[EMAIL PROTECTED]> wrote:
> I'm new to c++ coming from a c world. I'm so used to using c functions that
> I only end up using some c++ in programming. I mean I use the inheritane,
> overloading, virtual functions, etc. But when It comes to ex file io i end
> up using fopen(), fclose(), etc instead of the iostream. Is this a big deal
> in mixing and matching? Any problems when doing stuff like this?
>
> Thanks
>
some systems C headers are not C++ aware although glibc is ok. If you started
mixing iostream with fopen (and friends!), then nothing is guarenteed, just like
mixing new and malloc.
Using virtuals, polymorphism etc with fopen is ok as they address different
concepts.
karl.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Critical sections and spinlocks in Linux
Reply-To: [EMAIL PROTECTED]
Date: Tue, 12 Sep 2000 22:50:43 GMT
On Tue, 12 Sep 2000 17:27:56 -0500, Brice Breeden <[EMAIL PROTECTED]> wrote:
>I have a portable C++ multi-threading library for
>Windows/Linux and I'm trying to find the
>fastest possible mutual-exclusion API in
>Linux from user mode. I'm assuming that the
>increased efficiency implies that locks
>are only performed within the same process.
>
>Here are the two classes I'm using:
>
>Mutex uses a pthreads mutex or a System V semaphore,
>depending on whether it is shared between processes.
>
>Spinlock is meant for use in a single process. Currently,
>I'm using a pthreads mutex. I'd like to know if there's
>a faster alternative on Linux from user mode. The reason
>I'm asking is that Windows defines a mutex as well as
>a critical section.
glibc 2.2 implements the pthread_spinlock_t type and operations. These are
implemented as assembly routines that just do naive spinning (no backoffs).
This is now in beta, (glibc-2.1.93 is the latest test release, I think).
Glibc linuxthreads mutexes are fairly light-weight, but not enough for some
people. In glibc 2.2, there is a new non-portable mutex attribute type called
PTHREAD_MUTEX_ADAPTIVE_NP. This mutex type has some of the qualities of a
spinlock (only when running on SMP!). Namely, it spins around to try the lock
some number of times before giving up and suspending. That number of times is
determined from a dynamic smoothed average of past counts that is recorded in
the lock. Additionally, this mutex type does not implement any fairness: when
a mutex is unlocked, it is not guaranteed to be given to one of the waiting
threads, but to any thread which comes along and grabs it first. It's possible
that this mutex type will meet the needs of anyone looking for a fast,
lightweight, non-recursive lock that has prudent behavior on a single processor
machine, and more aggressive behavior on SMP.
>NOTE: The reason for having two classes is that the
>Mutex has more features (such as timeouts).
The function pthread_mutex_timedwait() is only implemented in the glibc 2.2
stream, not in any current release. Since, as you mentioned, your Mutex class
is done in terms of pthread_mutex_t, it cannot, for the time being, support
timed-out mutex locks. I suggest you use a mutex, condition variable and a
flag if you need timed-out locks today.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: Jerry Peters <[EMAIL PROTECTED]>
Subject: Re: Wish for a writable ISO-9660 compatible filsystem
Crossposted-To: comp.os.linux.misc
Date: Tue, 12 Sep 2000 22:56:09 GMT
In comp.os.linux.development.system Kasper Dupont <[EMAIL PROTECTED]> wrote:
> Johan Kullstam wrote:
>>
> [...]
>>
>> what about tar? can you make a big tar file and then burn it straight
>> off to the cd-writer? list with tar tvf /dev/cdrom and extract using
>> tar xvf /dev/cdrom just like when using a tape. maybe a cpio archive
>> would be better?
>>
Why? Ext2 is _slow_ on a cdrom, but this would be even slower. Tar
reads the archive sequentially to find a file, doesn't it? Now you've
also lost the ability to look at the cd and just find the file you
want, assuming you just want a few files. The only advantage I can see
would be the compression using tar -czf ...
Jerry
> That would probably work, there just are a few problems about the
> end of the file. The filesize must be a multiple of 2048, and there
> might be problems reading the last sectors of the disk.
> (I think there are more problems with TAO than DAO)
> So you would take a .tar or a .tgz file, append an appropriate
> number of zero bytes, and then send that to the cd-writer.
> Using a .tgz file and pad with at least 100KB of zeros would
> absolutely work.
> --
> Kasper Dupont
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: scheduling under Linux not suitable for interactive work?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 12 Sep 2000 22:57:48 GMT
On 13 Sep 2000 09:36:57 +0000, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
>Hello all!
>
>I have recently experienced, not for the first time, a complete
>choking of the system (Linux 2.2.14) when I ran an editting session
>(emacs) at the same time as some compute intensive tasks. I did not
>play with priorities or nice values. I was practically unable to edit,
>it took tens of seconds for characters to appear, or mouse pointer to
>move. On another occasion, I was editting a big file (~2Mb) and I ran
>a text replacement command on the whole buffer. The system froze and I
>couldn't do anything until the replacement command finished (after
>couple of minutes).
There is something wrong with your system. I haven't seen behavior like
that since using Linux 0.99 on a 386 with 4 megs of RAM with multiple users
logged in, compiling their projects.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
** 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
******************************
