Linux-Development-Sys Digest #375, Volume #8 Mon, 25 Dec 00 23:13:07 EST
Contents:
QUES: C++ Classes for unix system calls (Tom J)
Re: Char device drivers and mknod ("Satis Loire")
Re: OT: stupid democrats? (Paul Repacholi)
Re: Do "Lions' Commentary on UNIX" good for knowing unix kernal? (Paul Repacholi)
Re: A faster memcpy and bzero for x86 (Paul Repacholi)
Re: A faster memcpy and bzero for x86 (Robert Redelmeier)
Re: Char device drivers and mknod (Petric Frank)
Re: RAD for device drivers? (Peter =?ISO-8859-1?Q?K=F6hlmann?=)
Re: Compiling glibc 2.2 (Juergen Heinzl)
mitch555@x (removing mouse causes Linux to crash/hang. kernel 2.4, test7)
Re: Compiling glibc 2.2 ("Fruitbat")
Re: removing mouse causes Linux to crash/hang. kernel 2.4 (Robert Redelmeier)
Re: QUES: C++ Classes for unix system calls (Chetan Ahuja)
It it kernel's problem? (Chih-Chang Hsieh)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Tom J)
Subject: QUES: C++ Classes for unix system calls
Date: Mon, 25 Dec 2000 13:25:13 GMT
Hello. Are there classes in C++ for unix system calls? Especially
under linux? Also POSIX stuff.
My boss is asking.
By the way, have you ever seen a DOS C hacker rewrite all of your
threaded POSIX unix code to replace the threads with alternation in
one thread between different activities; replace your driver modules
with direct I/O port access by the applicaiton level; replace POSIX
signals with old unix signals and signal handlers; replace your
private_XtMainLoop with an occassional peek at the XEvent queue from
the main thread, and then force these changes down the throat of the
project as riders other features that are due? What did you do?
--
Tom J.; tej at world.std.com Massachusetts USA; MSCS; Systems Programmer
Dist. Real-Time Data Acquisition S/W for Science and Eng. under POSIX,
C, C++, X, Motif, Graphics, Audio http://world.std.com/~tej
------------------------------
From: "Satis Loire" <[EMAIL PROTECTED]>
Subject: Re: Char device drivers and mknod
Date: Mon, 25 Dec 2000 21:22:28 +0800
Hi Petric,
usually we don't hack the mknod source and mknod in device driver.
I understand there is no devfs in 2.2.x kernel, but we do have the
/proc/device.
So you can write a module loading script and get the dynamically assigned
major
no. from the /proc/device. here is a simple example,
#!/bin/sh
module="mymodule"
device ="mydevice"
#invoke insmod with all arguments
/sbin/insmod -f $module $* || exit 1
#get the dynamically assigned major no. and store it in the variable major
major='cat /proc/devices |awk "\\$2==\"$module\" {print \\$1}"'
#mknod with the value of $major.
mknod /dev/${device}0 c $major 0
mknod /dev/${device}1 c $major 1
mknod /dev/${device}2 c $major 2
hopefully this can help.
satis
"Petric Frank" <[EMAIL PROTECTED]> ????? news:[EMAIL PROTECTED]...
> Hello David,
>
> David Wragg schrieb:
> >
> > Petric Frank <[EMAIL PROTECTED]> writes:
> > > I am interested on the reason not to do this (mknod in device
drivers).
> > > Actually i can not understand why i should not code it into the
driver.
> >
> > Kernel code takes up unpageable memory. Is there any reason why you
> > can't do a "mknod" in a script to be run when the driver is installed,
> > perhaps even in the driver's Makefile?
>
> 2 Reasons:
>
> 1. The driver gets the major device number at load time from the kernel
> (when registering it via register_chrdev). So at installation time the
> major device number is not known.
>
> 2. Resulting from above and assuming that the driver is loaded
> automatically (entered in /etc/modules.conf): The entry in /dev must be
> generated automatically at load time of the character device driver.
> Remember: i'm at kernel 2.2.x (not 2.4.x - there is no devfs).
>
> Therefore i am asking for a 'mknod' source, because the functions in
> glibc (the function is mknod) are not callable by a device driver.
> (okok, i may analyze the glibc source to get the code, but if someone
> has a code snippet for me it will be much easier).
>
> > David Wragg
>
> regards
> Petric
------------------------------
Crossposted-To: comp.lang.c++,gnu.misc.discuss
Subject: Re: OT: stupid democrats?
From: Paul Repacholi <[EMAIL PROTECTED]>
Date: 26 Dec 2000 00:02:01 +0800
[EMAIL PROTECTED] writes:
> Yes, but don't blame Florida. They voted for Gore.
No, they voted for Electoral College delegates.
When THAT votes is counted, we will see.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
------------------------------
Crossposted-To: comp.unix.programmer,comp.os.linux.development
Subject: Re: Do "Lions' Commentary on UNIX" good for knowing unix kernal?
From: Paul Repacholi <[EMAIL PROTECTED]>
Date: 25 Dec 2000 23:54:08 +0800
[EMAIL PROTECTED] (Joe Humrickhouse) writes:
> On Tue, 19 Dec 2000 12:38:15 +0800, Carfield Yim
> <[EMAIL PROTECTED]> wrote:
> > From many classic review, the book "Lions' Commentary on UNIX 6th
> > edition : with source code " is the most excellent point of learn unix
> > system. So I borrow it from my library, and then I find out that it is
> > the source code with comment, as it state, but nothing more. Seen to me
> > that it is a bit harder to read because I am a java programmer. Only
> > learn C, ASM and Unix programming at college, with really less
> > experience of these stuff. Do this book still suitable for me? or is
> > there are better choice to learn more about Unix kernal?
>
> Try these:
> _The Design and Implementation of the 4.3BSD UNIX Operating System_ by
> Leffler, McKusick, Karels and Quarterman
> _Operating Systems Design and Implementation_ by Tanenbaum and
> Woodhall
> _The Design of the UNIX Operating System_, Bach
Try to also get some breadth into your readings. All Unix is
a very small part of the OS world view.
Hydra C.mmp. An experimental system. Wulf et al.
Covers the hardware and software. Capabilities based system.
The IBM 360/370 papers. ( keep aspro handy while reading )
Trailing-egde.com has Tops-10 and TOPS-20. Hard one. Almost
ALL in Macro-10 and some BLISS. Tops-10 is older than ANY
unix, and was the first time-sharing OS sold.
If you can get them, the VMS Listing Fiche.
Also, the RSX kits have full kernel sources in them, with
comments. RSX is the 'base design' for VMS and NT.
Hang out in comp.os.research. Their FAQ has pointers to
research systems you can often download.
If you can find them, I hear the Burroughs kernel sources
are worth reading just for the humour.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
------------------------------
Subject: Re: A faster memcpy and bzero for x86
From: Paul Repacholi <[EMAIL PROTECTED]>
Date: 26 Dec 2000 00:22:28 +0800
Robert Redelmeier <[EMAIL PROTECTED]> writes:
> Of course, this is predicated on the CPU having some idle time
> to do the pre-zeroing. AFAIK, most machines do. Even 99% load
> means one jiffy per second available. One jiffy is ~ 5M CPU clks,
> enough to zero 400 page although I wouldn't recommend zeroing that
> many--too much cache distruction. But blowing away the caches is not
> as harmful on an idle machine as one working that wants to write RAM.
Also consider that you have looked at ONE machine. In the Alphas
it varies with model. The 264s can zero memory without sweeping
the cache. And without reading memory. Allocate cache with modify,
then evict. Repeat.
The other thing you have missed is that if FPish code is used in
the kernel, then every context save/restore must do the FP registers,
and also take an FP latency that that requires.
A DMA memory stamper would be an interesting 3rd option to consider.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
------------------------------
Date: Mon, 25 Dec 2000 13:58:35 -0600
From: Robert Redelmeier <[EMAIL PROTECTED]>
Subject: Re: A faster memcpy and bzero for x86
Paul Repacholi wrote:
>
> Robert Redelmeier <[EMAIL PROTECTED]> writes:
> > Of course, this is predicated on the CPU having some idle time
> > to do the pre-zeroing. AFAIK, most machines do. Even 99% load
> > means one jiffy per second available. One jiffy is ~ 5M CPU clks,
> > enough to zero 400 page although I wouldn't recommend zeroing that
> > many--too much cache distruction. But blowing away the caches is not
> > as harmful on an idle machine as one working that wants to write RAM.
>
> Also consider that you have looked at ONE machine. In the Alphas
> it varies with model. The 264s can zero memory without sweeping
> the cache. And without reading memory. Allocate cache with modify,
> then evict. Repeat.
Indeed. The Alpha 21264 is in many ways a very interesting chip that
x86 is only beginning to catch up with, and in some ways never will.
I was considering the common x86, specificly the popular P6 (PPro,
P2, Cel) as sort of a cache worst-case. Later processors like the
K7 (Athlon, T'bird, Duron) and P3 have specific instrs to bypass cache.
> The other thing you have missed is that if FPish code is used in
> the kernel, then every context save/restore must do the FP registers,
> and also take an FP latency that that requires.
I've dealt with that earlier in the thread. FP/MMX is of no benefit
on P6 because of special hardware-acceleation on repeat string instr.
FP/MMX is of most benefit on P5, and some still on K6 and perhaps K7.
Noteworthy is that FreeBSD does use the FPU on i586, but a full FPU
context save isn't necessary.
> A DMA memory stamper would be an interesting 3rd option to consider.
Yes. x86 is missing this. OTOH, you could always temporarily modify
the page table attributes to "non cacheable", do the writes and restore.
-- Robert
------------------------------
From: Petric Frank <[EMAIL PROTECTED]>
Subject: Re: Char device drivers and mknod
Date: Mon, 25 Dec 2000 23:38:48 +0100
Hello Satis,
Satis Loire wrote:
>
> Hi Petric,
> usually we don't hack the mknod source and mknod in device driver.
> I understand there is no devfs in 2.2.x kernel, but we do have the
> /proc/device.
> So you can write a module loading script and get the dynamically assigned
> major no. from the /proc/device. here is a simple example,
>
> #!/bin/sh
> module="mymodule"
> device ="mydevice"
>
> #invoke insmod with all arguments
> /sbin/insmod -f $module $* || exit 1
>
> #get the dynamically assigned major no. and store it in the variable major
> major='cat /proc/devices |awk "\\$2==\"$module\" {print \\$1}"'
>
> #mknod with the value of $major.
> mknod /dev/${device}0 c $major 0
> mknod /dev/${device}1 c $major 1
> mknod /dev/${device}2 c $major 2
>
> hopefully this can help.
This is very clear to me.
Scanning /proc/devices for loaded module and retrieve the major number
to be used for mknod.
But this is not executed is the module is automatically loaded
(configured via modules.conf).
The user (mostly this must be root) have to execute it himself. There is
no automatism.
Can this (a script) be entered into /etc/modules.conf in that way that
the script is executed if the kernel loads the module ?
This is the point i want to be solved.
First i thought the device node can be allocated by the module being
loaded (after registering itself). This seems not possible (am i right
?). It seems that i have to wait for kernel 2.4.x to get this behaviour,
right ?
> satis
regards
Petric
------------------------------
From: Peter =?ISO-8859-1?Q?K=F6hlmann?= <[EMAIL PROTECTED]>
Subject: Re: RAD for device drivers?
Date: Tue, 26 Dec 2000 00:18:34 +0100
[EMAIL PROTECTED] wrote:
> I had an idea for rapidly generating device drivers. Although
> Linux drivers are more and more frequently supplied with new hardware,
> it's still not always the case. So what about writing a program that
> reads in a WinNT driver and converts it to a Linux driver?
>
> Marlin
>
>
> Sent via Deja.com
> http://www.deja.com/
You wouldn't call this an idea if you had any of that (ideas namely) of
how different the OS's in question are. Each win-driver will make calls
to other DLL's from Windows or other parts of the driver software
(remember, in these days, a simple printer driver is no longer that, at
least under windows. It's quite amazing that it doesn't also switch the
coffee machine for those unhappy souls who are in charge of installing
these monsters) So the first thing such a program you're proposing would be
to chomp off all windows-shit from the real driver. The rest would still be
some undigestable stuff. Nope, except for some very few basic routines which
have nothing to interface to you couldn't get really that much off a windows
driver.
It could be different, if the source for windows were really free for
anyone to see, but even then VERY difficult
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: Compiling glibc 2.2
Date: 26 Dec 2000 00:27:09 GMT
In article <q0016.30162$[EMAIL PROTECTED]>, Fruitbat wrote:
>Sorry if this has been asked before, but I have scanned the news groups and
>cant seem to find an answer to my questions.
>
>I'm running RedHat 6.2 and a 2.2.18 kernel on my intel box, and wish to
>upgrade to glibc 2.2. I have downloaded the source and read the readmes and
>have a couple of questions before I start. I am also using PAM and shadow
>passwords, and GNOME if it makes a difference to my questions, I'm not sure.
>
>do I really need to down load and use the Berkeley db files, I know its
>available from www.sleepycat.com , and if so which version as there are
>several.
[-]
You can use a current libdb like the one that came with glibc-2.1.3. I'd
even advice you to do that as you can't just replace a current version,
it isn't going to be binary compatible as it isn't going to be compiled
with versioning support.
Aside from that compiling it on Linux is a bit of a pain IMHO, so if
you've no reason don't.
>what is the nss_db-2.2 and nss_lres-0.91 files, and do I need them?
[-]
It depends on whether you use or plan to use NIS or not.
>Also is there a later version of glibc-crypt than 2.1?
[-]
It's all in glibc-2.2, so none required.
Cheers,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: removing mouse causes Linux to crash/hang. kernel 2.4, test7
<[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup
Subject: mitch555@x
Date: 25 Dec 2000 16:27:12 -0800
Hello,
linux 2.4.0-test7 #3 SMP
I found out that, if I remove the cable of the mouse from the
back of the PC, linux hangs. had to reboot. this happens everytime.
this can't be normal. right?
All I had to do is pull the mouse cable, and that is it. putting the
cable back has no effect. system dead. can't kill X, no response to
keyboard, nothing. dead as stone. only thing to do is reboot.
wonder if this is a known bug? others had the same problem?
thanks,
mitch
------------------------------
From: "Fruitbat" <[EMAIL PROTECTED]>
Subject: Re: Compiling glibc 2.2
Date: Tue, 26 Dec 2000 01:54:37 GMT
Thanx Juergen :)
------------------------------
Date: Mon, 25 Dec 2000 20:05:13 -0600
From: Robert Redelmeier <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup
Subject: Re: removing mouse causes Linux to crash/hang. kernel 2.4
> linux 2.4.0-test7 #3 SMP
>
> I found out that, if I remove the cable of the mouse from the
> back of the PC, linux hangs. had to reboot. this happens everytime.
PS/2 or serial mouse? PS/2 is not hot [un]pluggable and I'd
expect a hang if not hardware damage from hot unplugging.
AFAIK, RS232 serial ports are designed for hot-plugging and
shouldn't suffer.
-- Robert
------------------------------
From: Chetan Ahuja <[EMAIL PROTECTED]>
Subject: Re: QUES: C++ Classes for unix system calls
Date: 26 Dec 2000 03:01:50 GMT
Tom J <[EMAIL PROTECTED]> wrote:
> Hello. Are there classes in C++ for unix system calls? Especially
> under linux? Also POSIX stuff.
> My boss is asking.
> By the way, have you ever seen a DOS C hacker rewrite all of your
> threaded POSIX unix code to replace the threads with alternation in
> one thread between different activities; replace your driver modules
> with direct I/O port access by the applicaiton level; replace POSIX
> signals with old unix signals and signal handlers; replace your
> private_XtMainLoop with an occassional peek at the XEvent queue from
> the main thread, and then force these changes down the throat of the
> project as riders other features that are due? What did you do?
> --
No such personal experience but the word that immediately comes to
mind is "resign"...
Chetan
> Tom J.; tej at world.std.com Massachusetts USA; MSCS; Systems Programmer
> Dist. Real-Time Data Acquisition S/W for Science and Eng. under POSIX,
> C, C++, X, Motif, Graphics, Audio http://world.std.com/~tej
------------------------------
From: Chih-Chang Hsieh <[EMAIL PROTECTED]>
Subject: It it kernel's problem?
Date: 26 Dec 2000 03:02:22 GMT
Hello, all,
Is this is the right place to ask such a question?
We are running school web server on Linux 2.2.18.
But it crashes yesterday, we got following messages:
Has anyone get the same problem? Our H/W is:
PIII 800 * 2
1 GB RAM
U2W (sym53c895) SCSI interace
60 GB RAID
How could we solve this problem? Thanks in advance!
Dec 26 02:57:00 www kernel: Unable to handle kernel paging request at virtual address
00221984
Dec 26 02:57:00 www kernel: current->tss.cr3 = 00101000, %%cr3 = 00101000
Dec 26 02:57:00 www kernel: *pde = 00000000
Dec 26 02:57:00 www kernel: Oops: 0000
Dec 26 02:57:00 www kernel: CPU: 1
Dec 26 02:57:00 www kernel: EIP: 0010:[__fput+20/72]
Dec 26 02:57:00 www kernel: EFLAGS: 00010206
Dec 26 02:57:00 www kernel: eax: 00221960 ebx: f957f620 ecx: fbfc71b8 edx:
c092bff0
Dec 26 02:57:00 www kernel: esi: fbfc71b8 edi: fbfc2660 ebp: 00004000 esp:
ea053f58
Dec 26 02:57:00 www kernel: ds: 0018 es: 0018 ss: 0018
Dec 26 02:57:00 www kernel: Process make_wg_home_pa (pid: 6481, process nr: 58,
stackpage=ea053000)
Dec 26 02:57:00 www kernel: Stack: fb7e68c0 c0127cab f957f620 f957f620 f9960a80
c011d62e f957f620 fb7e68c0
Dec 26 02:57:00 www kernel: 00101000 ea052000 bffffdb0 f9960c80 c0114f58
fb7e68c0 fb7e68c0 fb7e68c0
Dec 26 02:57:00 www kernel: c0118736 fb7e68c0 ea052000 4013ef1c 00000000
bffffdb0 00000000 ea052000
Dec 26 02:57:00 www kernel: Call Trace: [fput+23/72] [exit_mmap+190/264] [mmput+28/52]
[do_exit+238/728] [sys_exit+15/16] [system_call+52/56]
Dec 26 02:57:00 www kernel: Code: 8b 40 24 85 c0 74 07 53 56 ff d0 83 c4 08 c7 43 08
00 00 00
--
Name: Chih-Chang Hsieh MailTo: [EMAIL PROTECTED]
Tel: +886-7-3121101 ext 2184 or 2290 Fax: +886-7-3133807
Org: KMU Computer Center Kaohsiung, Taiwan
------------------------------
** 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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
