Linux-Development-Sys Digest #668, Volume #7 Fri, 10 Mar 00 07:13:12 EST
Contents:
Re: Req. for info on rev. engineering an ISA (Backer) card (Kipp Cannon)
Re: FastTrak66 driver? (Vetle Roeim)
Re: kmalloc allocate swappable memory? (Alan Donovan)
Re: Bus-master PCI slots (Alan Donovan)
Re: Linux or Windows ("Mark Tranchant")
2.3.48 and spam?? (Mike Dowling)
Re: strange "pwdd <defunct>" processes running in Linux (Alan Donovan)
Re: kernel in C++ (Bernd Strieder)
Re: Can i get a MAC address ? (Peter Samuelson)
Re: 2.3.48 and spam?? (Peter Samuelson)
Re: Howto ignore tcp checksum?? ([EMAIL PROTECTED])
Re: How to determine the Maximum nymber of system call per seconds?
([EMAIL PROTECTED])
Re: kmalloc allocate swappable memory? (Marc SCHAEFER)
----------------------------------------------------------------------------
From: Kipp Cannon <[EMAIL PROTECTED]>
Crossposted-To:
alt.comp.hardware,comp.os.linux.hardware,comp.sys.ibm.pc.hardware.misc,comp.sys.ibm.pc.hardware.storage
Subject: Re: Req. for info on rev. engineering an ISA (Backer) card
Date: Fri, 10 Mar 2000 01:07:40 -0700
Oops,
Sorry, I forgot to put my real name and e-mail address back into
Netscape before posting that message. It should be correct in this
one. Again, sorry 'bout that. And thank-you to people who have
responded so far.
-Kipp
------------------------------
From: Vetle Roeim <[EMAIL PROTECTED]>
Subject: Re: FastTrak66 driver?
Date: 10 Mar 2000 10:51:17 +0100
* Harvey Taylor
> Hi,
> Does anybody happen to know about any Promise FastTrak66
> driver development happening?
what's that? a Ultra66 controller?
http://www.linuxdoc.org/HOWTO/mini/Ultra-DMA-5.html#ss5.2
vr
------------------------------
From: Alan Donovan <[EMAIL PROTECTED]>
Subject: Re: kmalloc allocate swappable memory?
Date: Fri, 10 Mar 2000 10:08:14 +0000
Fabrice Peix wrote:
>
> > Raj Suri wrote:
> >
> > I was curious as to whether or not the Linux kernal can swap pages of
> > memory to disk which were allocated using kmalloc in kernel space.
> > Or does that memory have to stay in physical memory? Is there any
> > resource that explains this in detail??
>
> Memory allocated using kmalloc can be swap.
Er, I think that's not true. Kernel addresses are simply physical
addresses shifted by some constant amount, they're not virtual
addresses. Therefore you can DMA to/from kernel buffers without further
action.
I don't claim to be an expert, but I'm pretty sure my undergrad OS
course said "UNIX kernel pages never swap".
alan
--
========================================================================
Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
Imerge Ltd. +44 1223 875265
------------------------------
From: Alan Donovan <[EMAIL PROTECTED]>
Subject: Re: Bus-master PCI slots
Date: Fri, 10 Mar 2000 10:15:05 +0000
"Timothy J. Lee" wrote:
>
> In kernels 2.0.* and 2.2.*, what are the ways to tell if a device
> is in a bus-master capable PCI slot?
Mastering capability resides with the card, not the slot itself. Look at
/proc/pci for a listing of what devices you have and whether they are
Master Capable. Look at kernel source drivers/pci/pci.c to find out how
it's done. Basically it's the PCI_COMMAND_MASTER (Master Enable) bit in
the PCI_COMMAND register for that device.
alan
--
========================================================================
Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
Imerge Ltd. +44 1223 875265
------------------------------
From: "Mark Tranchant" <[EMAIL PROTECTED]>
Subject: Re: Linux or Windows
Date: Fri, 10 Mar 2000 09:29:24 -0000
Paul Jackson wrote in message <8a9iss$gnl5r$[EMAIL PROTECTED]>...
>Dark wrote:
>> ps how do i get the menu @ boot time?
>I think Dark means a boot menu - which would list both Windows
>and Linux, so that he didn't have to boot Windows off a floppy.
>
>The 3 choices I am familiar with are:
>
> 1) System Commander
> 2) Boot Magic
> 3) lilo
and 4: a CONFIG.SYS menu, combined with LOADLIN. No "dangerous" messing
around with boot sectors.
Get an old MS-DOS 6.2 manual for instructions, or search on the Web.
Actually, I've posted this several times in the past, so you could try Deja.
Mark.
------------------------------
From: [EMAIL PROTECTED] (Mike Dowling)
Subject: 2.3.48 and spam??
Date: 10 Mar 2000 10:20:07 GMT
For the life of me, I cannot work this one out.
I had sendmail-8.10.0.Beta12 running since 28th Feb. In that time, I
had blocked spam via ORBS, DUL, and RBL, so it was working. Suddenly, I
received zillions of spams that were already listed in ORBS and RSS.
Although it seems to me far fetched, the only change to my system since
then was to replace the 2.2.14 kernel with 2.3.48. I have since updated
to 2.3.50, but could perhaps the networking code for the 2.3.48 kernel
have been somehow implicated?
Cheers,
Mike
--
My email address [EMAIL PROTECTED] above is a valid email address.
It is, in fact, a sendmail alias; the digit 'N' is incremented regularly.
Spammed aliases will be deleted. Currently, mike[21,22]
are valid. If email to mikeN bounces, try mikeN+1.
------------------------------
From: Alan Donovan <[EMAIL PROTECTED]>
Subject: Re: strange "pwdd <defunct>" processes running in Linux
Date: Fri, 10 Mar 2000 10:30:07 +0000
morgan wrote:
> Are these zombie processes, how do I get rid of them?
Kaz has addressed your security issues; however:
Zombie processes are entries in the kernel process table for processes
that have died. The entry just contains the termination status of the
process, which is either its return code (i.e. what it passed to
_exit(int)) or an indication that it died abnormally.
In themselves they are harmless and not really a waste of any resources,
but they are an indication that your program is forgetting to wait for
its children.
When you fork() a child, you should subsequently wait() for it, to get
its termination status, and then the process will disappear. In the
period between the child exiting and the parent waiting, the process is
a zombie; if the parent never waits, the child remains a zombie. When
the parent finally exits, the zombie child is finally reaped by init
(process 1).
If you don't want to wait for child processes, set your SIGCHLD
disposition to ignore signals from the child process; this will cause
them to be immediately reaped upon exit.
Read Stevens / "Advanced Programming in the UNIX Environment", or the
comp.os.unix FAQ for all the details.
alan
========================================================================
Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
Imerge Ltd. +44 1223 875265
------------------------------
From: Bernd Strieder <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Date: Fri, 10 Mar 2000 11:41:28 +0100
Hi
Kaz Kylheku wrote:
>
> On Thu, 09 Mar 2000 20:26:00 -0800, Saurabh Shrivastava <@efi.com> wrote:
> >hi everybody,
> > people say, kernel cant be written in C++. Is it true ?
>
> You can't write a kernel in C++ or C. That is to say, if you take the ISO C or
> C++ standard and stick to the language features described there, you won't get
> anywhere.
>
> To make a kernel, you have to provide supporting code to glue the system
> to the hardware. Also, you have to provide whatever run-time support
> the language needs.
>
> This run time support is bigger in C++, primarily due to the exception
> handling (which, of course, you *can* do without).
But in many occasions you can do a lot easier, i.e. with less code to be
written, if you use it. The biggest advantage is obtained if there is a
proper library making well-thought use of EH. This makes it very easy
for clients of that library.
>
> Also, the operations new and delete are a little bit naive in C++. If you look
> in the Linux kernel, you have atomic allocations, DMA-able allocations, page
> allocation versus kmalloc, etc. Memory allocation in embedded work is
> sometimes a bit of a hodge podge; not the clean ``one-size-fits-all'' paradigm
> provided by new and delete. Even overriding new and delete on a class basis
> might not be enough, because the same class object may need to be allocated
> in different ways in different circumstances.
The plain vanilla new and delete are most often just wrappers of malloc
and friends. But what about placement new and delete. They give the
opportunity to develop every memory handler you like. They are designed
for enabling use of shared memory areas between processes, for example.
So they should fit the other purposes as well.
>
> Global constructions are another pain in the ass in C++. In C you know that a
> static variable can be initialized before the kernel starts, or before your
> module is executed, and so on.
Global constructors are a pain in the ass anyways, since they create
global objects. The additional problem of C++ is just that pieces of
code are involved.
>
> What happens with something like
>
> void foo()
> {
> static int x = compute();
> }
>
This is another kind of global variable. If there is concurrent access
in different execution contexts this bites you anyways. A common way of
synchronizing among those is needed to get it right. So C++ makes this
problem just a little bit more obvious. One would do to it the very same
way in C and C++ to resolve this problem, in C++ mainly to resolve the
race condition, in C mainly to mimic the feature, and both versions
would probably use some kind of additionally protected flag to implement
it, like you propose some lines below.
> This is not allowed in C, for very good reasons. The crazy C++ language
> allows it. Compilers do evil things behind your back to support that.
> For example, g++ generates a secret flag variable associated with
> the x object. The initialization is actually translated into something
> like this:
>
> if (_secret_flag_x == 0) {
> x = compute();
> _secret_flag_x = 1;
> }
>
> can you say race condition? The problem with this construct is that there is
> no way to implement it right for all circumstances. Eliminating the race
> condition depends entirely on the execution context. The solution would be
> different if two or more kernel threads were to execute the code correcty,
> versus two or more interrupt service routines, or two or more user-level POSIX
> threads.
>
> C++ is full of this kind of crap that requires implementations to do things
> behind the programmer's back---things that require dubious assumptions
> regarding the execution environment and context.
You say crap, but this crap has been designed to make programmers life
easier, and it can do that if properly used and properly shielded from
concurrent writing access.
>
> Look at the exception handling support in libgcc.a . It contains calls to the
> pthread_* functions, or other, depending on the platform. To do C++ exception
> handling in the kernel, this support code would have to be retargetted to
> the constructs supported by the kernel.
To allow this to be done in a somewhat proper manner, the compiler would
have to give an interface for the clients, here the kernel, to specify
thread context and some synchronization mechanisms. It is a pity that
C++ has not included this, but this is clear, since there is no
standardized way to do this. This would enable to adapt to the C++
features more easily. I hope that someone capable of doing it sometimes
finds the time to include it in g++. C++ needs this as well. If this
experiment gives good results, chances would rise, that other compilers
and the standard in the end could adopt it.
What I don't like in linux kernel, when I'm reading it (I did sometimes
to find the reason for particular problems) are lines of the following
kind (just randomly chosen):
ips.c: if (scb->target_id <
ha->adapt->logical_drive_info.no_of_log_drive &&
ips.c:
ha->adapt->logical_drive_info.drive_info[scb->target_id].state !=
OFF_LINE &&
isdn_common.c: unsigned int minor =
MINOR(file->f_dentry->d_inode->i_rdev);
isdn_common.c: if
(((dev->drv[d]->interface->features & features) == features) ||
isdn_tty.c:
(!skb_queue_empty(&dev->drv[info->isdn_driver]->rpqueue[info->isdn_channel]))))
{
isdn_tty.c:
__skb_queue_tail(&dev->drv[info->isdn_driver]->rpqueue[info->isdn_channel],
skb);
If you want to understand these lines, you have to read a bunch of
header files and you have to find where these values have been set to
get an idea. In the end you have read the whole module and perhaps some
others until you have understood it far enough.
This makes everybody used to C++ cry, really. How to understand that
anybody is willing to work on code convoluted that much. The interface
you are faced with at one time seems just to be the whole thing. So I'm
not surprised that the wish to use C++ rises as more people try to look
at the kernel, finding that stuff. This is as closed as open source can
be.
I used to program code of similar kind, and the people involved in that
project understood what is going on since it was the daily work. But
others had a hard time. The ideas we had were used for another project,
but not our code, although every function and all data structures were
documented. Our code was still not readable because of the same reason
as above snippets of the kernel, you need to read at many places at
once. This is the way C makes you doing your stuff, resulting in a very
delayed learning curve for others.
The kernel has many parts, some seem to be better in the matter I wrote
about, others rather bad, where lines of the kind I cited are piled up
from the very beginning to the end. But one thing is clear, as long as
those famous dereferencing chains are common, there is no usable
interface, giving you a reasonable base for easily understanding the
kernel, which is a prerequisite to start working on it.
If there is a chain of the kind:
blaobj->foomemb[someindex]->anymember.info[anotherindex.value] =
(*whatever.fptr)(datax);
then a C++ programmer has just one question, why doesn't blaobjs
interface provide a function doing that highly convoluted chain for me,
or reducing it at least? There is inlining, the compiler could end up
producing nearly the same output as the handcoded madness. Why must I do
that dumb stuff the compiler is so much better at than I? Although it's
three sentences I wrote, it will sound like one question.
blaobj->setdatay( whatever.transform(datax) );
The methods setdatay and transform could be documented at the usual
places, there are systems providing indices and keyword search on
HTMLized docs of your projects. A little bit of click and you know what
is going on. In my experience it is not much work to document proper
interfaces in a usable way. As said there is inlining, we could end up
with nearly the same object code, with a readable source.
Really, I admire the people who write and maintain that kernel stuff in
the first place, but I adore those who take it up from others,
understand, and change it, pushing it forward its way.
It had to be said.
Bernd Strieder
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Can i get a MAC address ?
Date: 10 Mar 2000 04:53:23 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Alan Donovan <[EMAIL PROTECTED]>]
> As always, the method is: find a program that does it (ifconfig in
> this case), strace it and/or look at the source code, which can be
> found automatically by using rpm -qpi and rpmfind.net (if you use
> RedHat).
Yes! How often do these questions come up?
* How do you figure out which raw blocks your file is using? (Look in
the LILO source and see how Werner does it.)
* How do you get your own MAC address(es)? (Look in the ifconfig
source and see how they do it.)
* How do you change ext2fs file attributes? (Look in the chattr source
and see how they do it.)
* How do you pass file descriptors through sockets? (Look in the
apache source and see how they do it.)
* How do I read a utmp or utmpx file? (Look in the source for any
version of finger and see how they do it.)
etc., ad nauseum. Use the source, people -- *that's why it's there.*
I get the feeling there are a *lot* of folks out there that simply *do
not get* the open source movement. This is really what it's all about:
being able to reuse someone else's work, being able to take advantage
of the fact that someone else already looked up or figured out the
answer you need. For what I do on a typical day, the "huge library of
working example code" aspect of open source is often as important as
the "can make local modifications" aspect, which is what seems to get
most ot the attention.
The fact that having source code in hand can actually be *useful* for
something, and not just in the abstract or symbolic sense, does not
seem to occur to some people.
So endeth this morning's rant.
Peter
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: 2.3.48 and spam??
Date: 10 Mar 2000 05:04:58 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Mike Dowling <[EMAIL PROTECTED]>]
> I had sendmail-8.10.0.Beta12 running since 28th Feb. In that time, I
> had blocked spam via ORBS, DUL, and RBL, so it was working.
> Suddenly, I received zillions of spams that were already listed in
> ORBS and RSS.
>
> Although it seems to me far fetched, the only change to my system
> since then was to replace the 2.2.14 kernel with 2.3.48. I have
> since updated to 2.3.50, but could perhaps the networking code for
> the 2.3.48 kernel have been somehow implicated?
Strange as it may seem, yes, it could have been. There was an issue
with changing some semantics of UDP networking, and since DNS uses UDP,
this could easily have affected your DNS timeouts, and of course RBLs
are based on DNS. I have not been following kernel development of
late, so I don't know any more than what Kernel Traffic reports:
http://kt.linuxcare.com/kt20000306_57.html#6
Peter
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Howto ignore tcp checksum??
Date: Fri, 10 Mar 2000 11:05:15 GMT
The ACEnic Gigabit ethernet network card support tcp checksum in
hardware, soI think that must a method to prevent tcp from doing
checksum as it is done in hardware.
In article <[EMAIL PROTECTED]>,
Alan Donovan <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > How to prevent tcp from doing header checksum calculation. Hence
we
> > can save some CPU loading???
>
> I doubt that's a good idea. TCP header checksumming is probably not
your
> bottleneck. And oh yes, TCP is called a "reliable" protocol for a good
> reason.
>
> Try profiling your code, and if you can be more expansive about your
> problem, so can we about the solution.
>
> alan
>
> --
> ----------------------------------------------------------------------
--
> Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
> Imerge Ltd. +44 1223 875265
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to determine the Maximum nymber of system call per seconds?
Date: Fri, 10 Mar 2000 11:08:30 GMT
In article <[EMAIL PROTECTED]>,
Alan Donovan <[EMAIL PROTECTED]> wrote:
>
> Why do you ask, anyway?
>
> alan
>
I think a limitation of system calls will limit the trhoughput of
the gigabit ethernet card.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Marc SCHAEFER <[EMAIL PROTECTED]>
Subject: Re: kmalloc allocate swappable memory?
Date: 10 Mar 2000 08:58:09 GMT
Raj Suri <[EMAIL PROTECTED]> wrote:
> This is a multi-part message in MIME format.
argh.
> I was curious as to whether or not the Linux kernal can swap pages of
> memory to disk which were allocated using kmalloc in kernel space. Or
no. It's a design choice: else you would have to resolve the chicken
and the egg problem (e.g. your SCSI driver allocates its SCSI command
structures with kmalloc(), and they are swapped to a SCSI disk).
You CAN resolve that chicken and egg problem, infact it is resolved in Linux.
You simply have two different memory allocators.
kmalloc()
Allocated physical memory, which is then mapped in kernel space.
With special flags, supports ISA DMA (GFP_DMA), and also supports
atomic allocation (GFP_ATOMIC). The standard allocation policy
(GFP_KERNEL) needs a context (process/task), since to get that
memory some processes's data can be migrated to disk. GFP_ATOMIC
can be used in interrupts, without it you can't. Infact GFP_ATOMIC
can allocate from the wasted memory (ie the real free unused memory).
Also, in the general case kmalloc() allocates physically contiguous
memory. But it's limited in size (I think max is 128k).
kmalloc() is implemented with get_free_pages().
vmalloc()
This allocates memory which may not be physically contiguous.
It's how e.g. kernel modules are loaded. The CPU (through its MMU)
sees it as contiguous. However it's also unswappable.
I think that swappable memory allocation is done through sys_brk() for
user processes, and it's implemented as a mmap(), where actual memory
allocation is done with page faults.
If I am wrong, please correct me.
------------------------------
** 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
******************************
