Linux-Development-Sys Digest #404, Volume #8 Wed, 10 Jan 01 07:13:13 EST
Contents:
Re: measure time since program-start in ms (Josef Moellers)
Re: Linux device driver (Josef Moellers)
Re: compiling non-smp kernel on smp machine - wrong signature! (Josef Moellers)
2.4.0 Kernel Panic w/Adaptec 29160 (dohmar)
Re: Extending /proc filesystem on Solaris 7/8? (Neal Tucker)
software flow control for serial port ("Franz Keller")
Re: 2.4.0 Kernel Panic w/Adaptec 29160 (Kasper Dupont)
vm86 and virtual memory ("Eppie")
Re: Extending /proc filesystem on Solaris 7/8? (Casper H.S. Dik - Network Security
Engineer)
Re: Extending /proc filesystem on Solaris 7/8? (Kasper Dupont)
Re: software flow control for serial port (Josef Moellers)
Re: vm86 and virtual memory (Kasper Dupont)
Re: UNIX98 Pty's ???? ("Morten B�hmer")
interrupt handling (Ralf Edrich)
----------------------------------------------------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: measure time since program-start in ms
Date: Wed, 10 Jan 2001 11:14:12 +0100
Kasper Dupont wrote:
> =
> Ralf Edrich wrote:
> >
> > Hi,
> >
> > is it possible to measure the time since program-start with precision=
of
> > 1 ms ?
> >
> > All I've read about now deals with around 10 ms.
> >
> > tia,
> >
> > Ralf
> =
> A pentium can give you time in clockcycles.
There is no means to reliably synchronize TSC registers on multiple
CPUs. Current Pentium CPUs with TSC support can reset TSC registers to 0
with a write to the TSC register, but this feature may not be supported
on future CPUs.
The linux kernel will account for timer skew, but if you read TSC
registers from a user program (by executing the rdtsc instruction) there
is bound to be skew in the TSC timer values. Some MP motherboards/BIOSes
will even have huge (and I mean HUUUUUUGE) differences in the TSC values
for the various CPUs, because the multiple CPUs will not be started at
exactly the same time!
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: Linux device driver
Date: Wed, 10 Jan 2001 11:26:42 +0100
YAMAZAKI NINJA wrote:
> =
> Hi ,
> =
> What kind of device driver that we can find in Linux . As far as I know=
,
> we can divide it to 3 groups (character device,block device and network=
> device).Is it true ?
> =
> How do we classified these devices ? How about VGA card,sound card ? Ar=
e
> they character device ?
Put it this way:
There are block device and character device inodes giving you block
device and character device access. These interface to some portion of
the kernel which may not be a driver proper. E.g. when you access
/dev/sda0, this will not refer to a real device driver but to a piece of
kernel code that manages portions of SCSI disks which, in turn, may not
even be SCSI disks but IDE disks disguised as SCSI disks. Due to many
abstraction layers within the kernel, hardly any "device" really refers
to a real device any more.
Most device drivers provide an interface to a specific kernel subsystem,
e.g. the SCSI subsystem.
The soundcards are a good example of this: there are numerous entries in
the /dev subtree that refer to one aspect or another of the sound
subsystem and the drivers provide some service to the sound subsystem.
So perhaps the following model would describe this best (if I may say so
myself B-{):
There are block device and character device nodes in the linux
filesystem that give access to a specific linux kernel subsystem
providing two different sets of interfaces (e.g. you can mount a block
device and you can ioctl a character device, but not vice versa; you can
read any amount of data from a block device but only device specific
blocks of data from a character device ... confusing, eh?). There are,
however, other interfaces to other kernel subsystems, like network
interfaces (socket/bind/listen/connect etc).
Hardware drivers provide services to these linux kernel subsystems
though a subsystem-specific interface.
My 2 (euro-) cents,
Josef
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: compiling non-smp kernel on smp machine - wrong signature!
Date: Wed, 10 Jan 2001 11:27:38 +0100
Michal Szymanski wrote:
> =
> To speed up the build, I've compiled new kernel (2.2.16-3 from RedHat
> sources RPM) for a single-CPU, old 486 PC, on a fast dual-CPU
> machine. Needless to say, the CONFIG_SMP in the config file was
> NOT set. After installing the kernel to the 486 PC, it booted up
> without network, quite strangely. It seems that the reason is that
> the kernel has a 'smp' signature, so the 'depmod' command looks
> for /lib/modules/2.2.16-3smp directory while, of course, the modules
> are installed in /lib/modules/2.2.16-3.
> =
> I wonder whether this is a bug, easy to patch, or it is always so
> that non-smp kernel should be built on a non-smp machine.
> =
> any hints?
Check the first 4 lines in your /usr/src/linux/Makefile. They are
probably wrong.
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
Subject: 2.4.0 Kernel Panic w/Adaptec 29160
From: dohmar <[EMAIL PROTECTED]>
Date: Wed, 10 Jan 2001 20:58:07 +1030
Hi Guys...
Have had a bit of problems when compiling the 2.4.0 kernel with support for an
adaptec 29160 scsi card (7892 chipset)
System is an MSI-694D w/dual p800 coppermines. I have the latest bios update
(v1.6)
This only happens when I've compiled in the low level AIC 7xxx series module.
Here it is :
Unable to handle kernel NULL pointer reference at virtual address 00000020
printing eip:
c01f09d4
*pde =3N 00000000
Oops : 0000
Cpu : 1
EIP : 0010:[<c01f09d4>]
Eflags : 00010286
eax:00000000 ebx:c02ac340 ecx:c1272d60 edx:c1272d64
esi:c02ac374 edi:c7f69c14 ebp:0000000b esp:c123ff18
ds:0018 es:0018 ss:0018
Process Swapper (pid:1, stackpage=3Nc123f000)
Stack:c01ec6ff c0281060 00000000 c123ffa0 c7f69c40
00000000 ffffffff 00000000
00000002 00000000 00000000 00000000 00000000
c02808e8 c02808e7 00000000
0000002 0000000a c023a888 c123ff9c c02808e8
c123ff7c c01eb67a c123ff9c
Call Trace : [<c01ec6ff>] [<c0239888>] [<c01eb67a>] [<c01eb6b0>]
[<c01c9c4e>] [<c01c9c84>] [<c0105000>]
[<c01c9d78>] [<c0107031>] [<c0105000>] [<c0107507>]
code : 8b 40 20 c7 40 24 00 00 00 00 a1 a4 c3 29 c0 a3 c8 b5 31 c0
Anyhow I hope this helps...
I cant use my roms till its fixed :)
------------------------------
From: [EMAIL PROTECTED] (Neal Tucker)
Crossposted-To: comp.unix.solaris
Subject: Re: Extending /proc filesystem on Solaris 7/8?
Date: 10 Jan 2001 02:25:30 -0800
Philip Brown <[EMAIL PROTECTED]> wrote:
>In linux, there is this disgusting habit of "I dont have to write a
>real kernel API: i'll just make my driver dump ASCII text with a procfs dev".
>
>This makes it simpler to hack out a quick driver for linux, in some ways.
>But if you think about it, this is a very large enemy of portable coding.
>To have a portable interface... You actually have to
>*DEFINE* an interface.
>
>"Look through the ASCII dump of /proc/blah" is NOT a very good interface
>definition.
I agree completely. It's a horrible interface, and when I write
to it, I worry that my programs are going to break next kernel
release.
1) Half the documentation I've ever been able to find is out of
date and incomplete. Documentation/filesystems/proc.txt has,
for many sections, just *examples* of what you can expect.
Hardly a spec.
2) The other half is the source code, which is not exactly
reassuring (yeah, the source code shows me for certain that I
can parse the line with "%d.%02d %d.%02d %d.%02d %d/%d %d\n",
but that's not exactly a *promise*...just something I know is
true *right now*).
3) Why would I *want* to worry about converting a bunch of data
to and from ASCII? I'm sure I can think of other perfectly
good ways to add bugs to my code than having to worry about
whether the human-readable version of the process state is
allowed to have a space in it or not. All that, for what,
a byte of information? Great.
Those are my good reasons for hating proc. Then there are my
peeves:
1) It's a dumping ground. How does one find stuff in there?
Who decides what goes where? As it gets bigger, it only
gets worse.
2) What good is having it be a filesystem if every just hardcodes
"/proc/foo" in their code? What if I wanted to mount it under
some other directory? We might as well just say "the /proc
part of the filesystem namespace is off limits for storing
files, since you are required to mount a 'proc' filesystem
there."
-Neal Tucker
------------------------------
From: "Franz Keller" <[EMAIL PROTECTED]>
Subject: software flow control for serial port
Date: Wed, 10 Jan 2001 11:44:15 +0100
Hi,
can the serial device driver handle software flow control. I only
found the hardware flow contol (c_cflag CRTSCTS).
Thanks
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: 2.4.0 Kernel Panic w/Adaptec 29160
Date: Wed, 10 Jan 2001 10:52:02 +0000
dohmar wrote:
>
> Hi Guys...
> Have had a bit of problems when compiling the 2.4.0 kernel with support for an
> adaptec 29160 scsi card (7892 chipset)
> System is an MSI-694D w/dual p800 coppermines. I have the latest bios update
> (v1.6)
> This only happens when I've compiled in the low level AIC 7xxx series module.
>
> Here it is :
>
> Unable to handle kernel NULL pointer reference at virtual address 00000020
> printing eip:
> c01f09d4
> *pde = 00000000
> Oops : 0000
> Cpu : 1
> EIP : 0010:[<c01f09d4>]
> Eflags : 00010286
> eax:00000000 ebx:c02ac340 ecx:c1272d60 edx:c1272d64
> esi:c02ac374 edi:c7f69c14 ebp:0000000b esp:c123ff18
> ds:0018 es:0018 ss:0018
> Process Swapper (pid:1, stackpage=c123f000)
> Stack:c01ec6ff c0281060 00000000 c123ffa0 c7f69c40
>00000000 ffffffff 00000000
> 00000002 00000000 00000000 00000000 00000000
> c02808e8 c02808e7 00000000
> 0000002 0000000a c023a888 c123ff9c c02808e8
>c123ff7c c01eb67a c123ff9c
>
> Call Trace : [<c01ec6ff>] [<c0239888>] [<c01eb67a>] [<c01eb6b0>]
> [<c01c9c4e>] [<c01c9c84>] [<c0105000>]
> [<c01c9d78>] [<c0107031>] [<c0105000>] [<c0107507>]
>
> code : 8b 40 20 c7 40 24 00 00 00 00 a1 a4 c3 29 c0 a3 c8 b5 31 c0
>
> Anyhow I hope this helps...
> I cant use my roms till its fixed :)
If anybody is to get anything out of it the
IP values [<xxxxxxxx>] must be looked up in
the appropriate symbol table System.map-xx.
Check linux/Documentation/oops-tracing.txt
for more information.
--
Kasper Dupont
------------------------------
From: "Eppie" <[EMAIL PROTECTED]>
Subject: vm86 and virtual memory
Date: Wed, 10 Jan 2001 11:53:50 +0100
Hi,
I want to run a process in virtual 86 mode and I use the vm86 call,
but I don't know how its memory is organized.
I want to do something like:
mem = mmap(1MEGABYTE);
initialize this memory
call vm86
But how can I "link" the mmaped memory to the virtual proces?
Is a new proces created whenever vm86 is called, or is the process
calling the vm86 function call turned into a virtual proces? If the first
case: where/how is the memory located and/or how can I fill this memory?
In the second case the virtual proces uses the "normal" process memory
(I think) but how can I modify it to fill it with my application without
overwritting
the real process memoryt?
One note: the memory must be one megabyte and starting at 0, so the process
thinks it runs on a 8086 (duh, that is the sole purpose of this function)
and can
read/write from 0x00000 till 0xfffff.
Oh, one other question: the virtual proces may also remap its interrupt
vectors
and the good old timer interrupt of this virtual process must be called
periodically.
How can I do this all? Yes, I know there is dosemu. But that is too complex
to
understand the basic mechanisms (I don't want to emulate the whole DOS
functionality).
Thanks,
Erwin
------------------------------
From: [EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer)
Crossposted-To: comp.unix.solaris
Subject: Re: Extending /proc filesystem on Solaris 7/8?
Date: 10 Jan 2001 10:48:02 GMT
[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
[EMAIL PROTECTED] (Philip Brown) writes:
>/devices seems to be part of the regular root filesystem on solaris.
>But it's not like /dev, with character special or block special devices.
>Basically, it's a way to see how drivers are physically and logically
>interconnected.
>And beyond that, each entry in the tree is supposed to give back special
>properties.
All the character and block devices live *only* under /devices.
They're presented in a tree that makes sense to the kernel, not
to programs. These nodes are added automatically by drivers.
/dev contains the abstraction layer for programs; /dev/term/a
will always be serial port A on a desktop but it may point to
many different /device entries. The /dev nodes are added by the
device configuration framework; also more or less automatically.
The "text" representation of Linux /proc is perhaps interesting, but
it's really awful when it comes to writing code.
There's a good reason why /proc in Solaris contains binary files;
they're much easier to use for programs and they're much easier to
write code for.
#include <sys/procfs.h>
struct pfoo foo;
fd = open("/proc/<pid>/foo", O_RDONLY);
read(fd, &foo, sizeof foo);
Much simpler than
fscanf(FOO, fmt, &foo.foo_x, ....))
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.solaris
Subject: Re: Extending /proc filesystem on Solaris 7/8?
Date: Wed, 10 Jan 2001 11:14:35 +0000
Neal Tucker wrote:
>
> Philip Brown <[EMAIL PROTECTED]> wrote:
> >In linux, there is this disgusting habit of "I dont have to write a
> >real kernel API: i'll just make my driver dump ASCII text with a procfs dev".
> >
> >This makes it simpler to hack out a quick driver for linux, in some ways.
> >But if you think about it, this is a very large enemy of portable coding.
> >To have a portable interface... You actually have to
> >*DEFINE* an interface.
> >
> >"Look through the ASCII dump of /proc/blah" is NOT a very good interface
> >definition.
>
> I agree completely. It's a horrible interface, and when I write
> to it, I worry that my programs are going to break next kernel
> release.
>
> 1) Half the documentation I've ever been able to find is out of
> date and incomplete. Documentation/filesystems/proc.txt has,
> for many sections, just *examples* of what you can expect.
> Hardly a spec.
>
> 2) The other half is the source code, which is not exactly
> reassuring (yeah, the source code shows me for certain that I
> can parse the line with "%d.%02d %d.%02d %d.%02d %d/%d %d\n",
> but that's not exactly a *promise*...just something I know is
> true *right now*).
>
> 3) Why would I *want* to worry about converting a bunch of data
> to and from ASCII? I'm sure I can think of other perfectly
> good ways to add bugs to my code than having to worry about
> whether the human-readable version of the process state is
> allowed to have a space in it or not. All that, for what,
> a byte of information? Great.
>
> Those are my good reasons for hating proc. Then there are my
> peeves:
>
> 1) It's a dumping ground. How does one find stuff in there?
> Who decides what goes where? As it gets bigger, it only
> gets worse.
>
> 2) What good is having it be a filesystem if every just hardcodes
> "/proc/foo" in their code? What if I wanted to mount it under
> some other directory? We might as well just say "the /proc
> part of the filesystem namespace is off limits for storing
> files, since you are required to mount a 'proc' filesystem
> there."
>
> -Neal Tucker
I love /proc, it is fantastic that I can get almost
any information about the state of the system using
only cd, ls and cat. I don't have to remember lots
of strange commands and options to make it print
whatever information I'm seeking.
But it is not good that the system simply cannot
work without /proc mounted and that userspace
programs have to parse the files in there to get
some information.
But the syscall interface cannot be extended easily
and a misc char device is not a good idea either.
Having hardcoded "/dev/foo" in programs by your own
argument is a bad idea.
It would be nice for every file in /proc to have a
program that could extract and print the same output
without requiring /proc to be mounted.
But we have to design an efficient, extensible and
easy to use interface. Extensibility can only be
achieved using strings to reference the subsystem
you want to address. You should have a syscall that
given a string returns a descriptor that you can
from that point on use through a syscall to query
information from that subsystem.
This is very similar to a virtual filesystem with
an entry for each subsystem which can be queried
through ioctl's so why not do it that way?
If you call /proc for namespace polution then how
about /dev/null, /dev/console, /sbin/init and lots
of other names. You simply cannot design a system
without having some names fixed.
--
Kasper Dupont
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: software flow control for serial port
Date: Wed, 10 Jan 2001 12:15:48 +0100
Franz Keller wrote:
> =
> Hi,
> =
> can the serial device driver handle software flow control. I only
> found the hardware flow contol (c_cflag CRTSCTS).
look for IXON, IXANY, IXOFF in c_iflag and VSTART, VSTOP in c_cc[].
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: vm86 and virtual memory
Date: Wed, 10 Jan 2001 11:32:02 +0000
Eppie wrote:
>
> Hi,
>
> I want to run a process in virtual 86 mode and I use the vm86 call,
> but I don't know how its memory is organized.
>
> I want to do something like:
>
> mem = mmap(1MEGABYTE);
> initialize this memory
> call vm86
>
> But how can I "link" the mmaped memory to the virtual proces?
> Is a new proces created whenever vm86 is called, or is the process
> calling the vm86 function call turned into a virtual proces? If the first
> case: where/how is the memory located and/or how can I fill this memory?
> In the second case the virtual proces uses the "normal" process memory
> (I think) but how can I modify it to fill it with my application without
> overwritting
> the real process memoryt?
>
> One note: the memory must be one megabyte and starting at 0, so the process
> thinks it runs on a 8086 (duh, that is the sole purpose of this function)
> and can
> read/write from 0x00000 till 0xfffff.
>
> Oh, one other question: the virtual proces may also remap its interrupt
> vectors
> and the good old timer interrupt of this virtual process must be called
> periodically.
>
> How can I do this all? Yes, I know there is dosemu. But that is too complex
> to
> understand the basic mechanisms (I don't want to emulate the whole DOS
> functionality).
>
> Thanks,
> Erwin
You must mmap the memory at address 0 in your virtual address
space. You can do that by using the MAP_FIXED flag to mmap.
Also notice that you might have to mmap more than 1MB, you can
mmap up to 1088 KB where the last 64KB will be the HMA.
If you want to emulate a 8086 where that 64KB maps to the first
64KB you can do that using shmget, shmctl, shmat.
The vm86 calls take a struct as argument, the struct contains
more or less the internal state of the CPU. Emulating a 8086
requires a long sequence of vm86 calls with the same struct as
argument.
If you want to emulate a 8086 SMP system you can either do that
by having two different structs where you alternating call vm86
and one and the other or you could have two processes whith
shared memory maped at address 0.
Notice that at some time the vm86 call was renamed to vm86old
and a new vm86 call was introduced. You might have a mismatch
between kernel, libraries and header files which has to be
handled by your program.
I have made a PC emulator a litle different from DOSEMU, if you
want I can send you the source of some of my earlier versions,
that does litle more than emulating a CPU.
--
Kasper Dupont
------------------------------
From: "Morten B�hmer" <[EMAIL PROTECTED]>
Subject: Re: UNIX98 Pty's ????
Date: Wed, 10 Jan 2001 13:04:18 +0100
What should the inittab look like?
--
Med vennlig hilsen/Best Regards,
Morten B�hmer - [EMAIL PROTECTED]
AdCo Partner AS
Bjellandveien 14 - 3172 VEAR
[EMAIL PROTECTED]
http://www.veggers.no
"Karl Heyes" <[EMAIL PROTECTED]> wrote in message
news:93g2re$4ns$[EMAIL PROTECTED]...
> In article <93ejdf$d1r$[EMAIL PROTECTED]>, "Morten B�hmer"
> <[EMAIL PROTECTED]> wrote:
>
> > How am I supposed to get 'em to work?
> >
>
> have you mounted the devpts filesystem.
>
> karl
------------------------------
From: Ralf Edrich <[EMAIL PROTECTED]>
Subject: interrupt handling
Date: Wed, 10 Jan 2001 13:06:06 +0100
HI,
I've tried to set a new new interrupt-routine, based on "man 9
request_irq/free_irq".
Even though I did it exactly the same, errors are coming up just like as
if there
would be missing a header-file (or maybe a lib).
Is there any example out there or could anyone give me a hint?
tia,
Ralf
------------------------------
** 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
******************************
