Linux-Development-Sys Digest #198, Volume #7 Wed, 15 Sep 99 18:14:25 EDT
Contents:
UDMA vs IDE: performance comparison wanted (Philip Brown)
Re: Question: Preventing user processes from interfering with another... (Tristan
Wibberley)
Adding XML to Linux (Proposal Outline) (Howard B. Golden)
Re: UDMA vs IDE: performance comparison wanted ("Drydd")
insmod & printf problem ([EMAIL PROTECTED])
Re: unix98 pty's problems (Remco van den Berg)
Re: how to become a linux kernel developer? (Tristan Wibberley)
Re: UDMA vs IDE: performance comparison wanted (Philip Brown)
program/code/advice to find out about unknown keyboard buttons ? (Id Est)
Re: Adding XML to Linux (Proposal Outline) (Tristan Wibberley)
Question: Preventing user processes from interfering with another... (Markus Jochim)
Re: UDMA vs IDE: performance comparison wanted (Robert Krawitz)
Re: UDMA vs IDE: performance comparison wanted (Dave Platt)
Re: porting unnamed structures (Uwe Bonnes)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Philip Brown)
Subject: UDMA vs IDE: performance comparison wanted
Reply-To: [EMAIL PROTECTED]
Date: 15 Sep 1999 17:28:20 GMT
howdy,
I'm wondering if anyone has a chart of IDE vs UDMA performance. Ideally,
on the same machine using the same controller types, on the same
RPM speed drives.
--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]
http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:@@@D
The word of the day is mispergitude
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To:
alt.os.linux,alt.linux,alt.uu.comp.os.linux.questions,comp.os.linux.development,de.comp.os.linux.misc
Subject: Re: Question: Preventing user processes from interfering with another...
Date: Tue, 14 Sep 1999 21:23:44 +0100
Reply-To: [EMAIL PROTECTED]
Markus Jochim wrote:
>
> Hello everybody,
>
> I have got a question concerning the mapping from logical to
> physical addresses that takes place for example in a Pentium
> Processor.
>
> If you take a look at Intels documentation things seem to be
> roughly as follows:
>
> A segment selector points to a segment descriptor which gives
> you a segment base address. If you add the offset of the
> logical address to this base address you gain the linear
> address which might be mapped again to a different physical
> address if paging is on.
>
> I always thought that the following statement would be true:
>
> Statement A):
> "If you want to prevent two different user processes to be able
> to access each others memory, then both processes must
> be located in different segments. The processor then
> enforces boundaries between these segments and insures that one
> program does not interfere with the execution of another program
> by writing into the other program's segments."
>
> After I took a look into the linux kernel sources I found that,
> for example, the code segment selector (cs) for _every_ user program
> has the value 0x23. Debugging two identical copies of the same
> program at once with gdb showed me, that not only the value
> of the cs-register is identical in each instance, but also the
> offset-parts of all code adresses are identical.
>
> After taking another look at Intels processor documentation
> the only possible explanation that I found is the following:
>
> Statement B):
> "As part of a task switch, the processor can also switch to
> another LDT, allowing each task to have a different logical-
> to-physical address mapping for LDT-based segments. The
> page-directory base register (CR3) also is reloaded on a task
> switch, allowing each task to have its own set of page tables.
> These protection facilities help isolate tasks and prevent them
> from interfering with one another. If one or both protection
> mechanisms are not used, the processor provides no protection
> between tasks. This is true even with operating systems that
> use multiple privilege levels for protection. Here, a task
> running at privilege level 3 that uses the same LDT and
> page tables as other privilege-level-3 tasks can access code
> and corrupt data and the stack of other tasks."
>
> Now my questions are the following:
> 1) Are the two protection mechanisms mentioned in statement B used
> by linux?
> 2) Is the statement A) wrong?
To 1), yes - though the segment protection is redundant since page
protection is capable enough on it's own - the segmentation is only used
because ia32 requires it. On other architectures, Linux uses only
paging.
To 2) - No, if two processes have segments that overlap and the logical
addresses are mapped directly to the physical ones they share that
memory. With paging, the same logical address can point to completely
different memory. Linux uses the paging to allow two processes that
access the same logical address to have their own data there instead of
sharing (which is an option).
Note I'm setting followups to comp.os.linux.development.system only -
you went over the top. Please don't crosspost so much in future.
--
Tristan Wibberley
------------------------------
From: Howard B. Golden <[EMAIL PROTECTED]>
Subject: Adding XML to Linux (Proposal Outline)
Date: Wed, 15 Sep 1999 17:53:00 GMT
(I posted this as a talkback on linuxtoday.com, but I guess here is
better.)
MS is touting the universal benefits of XML. I totally agree with that
part of their DNA vapor. Here's how it can really mean something:
About two months ago, I started writing a plan for adding XML to Linux
(and POSIX in general). I got bogged down, but I'm going to give the
basic outline here. I hope there will be some interest in starting a
bazaar project to actually implement this.
Bear with me as I give a bit of quasihistory: A key benefit of Unix was
its organization around text files. Programmers were encouraged to
write "filters" that would transform the input text file into the
output text file. Unix included pipes to make it easy to string these
filters together.
Text files can handle a lot of problems, but they can't handle many
important things. So I propose adding additional "paradigms." (I hope
we can find a better word.)
The most obvious to me is a tree structure. What I have in mind is
adding features to programs that make it easy to design filters that
take trees as inputs and return trees as outputs. (A text file is a
simple tree, consisting of either one leaf (the whole file), or as many
leaves as there are characters, or as many leaves as there are lines,
depending on how you look at it.) I'll say more about the
implementation below.
You may be wondering what this has to do with XML. The point is, XML
can represent many tree structures. (Can it represent all? I don't
know, but maybe a theoretician can answer.) I propose to use XML as
the "external" (between computers) way of transmitting trees. Within
the computer, trees might be represented using an object-oriented
structure that wouldn't require a text representation.
How could this be implemented? Here's my first thought: Currently,
programs get two parameters at their "main" entry point, argc and argv,
a count and a list of text string, respectively. They read
from "stdin" and write to "stdout", which are assumed to be text
streams. What if we set up a new entry point, say "xmain" that gets a
single "xarg" (which is a tree). The program can read (or
process) "xstdin" and write "xstdout", which are also trees.
You may be asking "So what?" Here's my answer: The "xarg" is a tree,
but it's not any arbitrary tree. It must conform to a specific
grammar, the program's option grammar, and this can be tested by a (to
be written) standard subroutine. This grammar would be the permissible
arguments, from the man page, expressed as a tree structure (or an XML
schema). Similarly, the "xstdin" and "xstdout" would have defined
grammars for them, which can also be tested against the supplied trees.
"So what?" you ask again. Here's what: Now we have a way of specifying
program options using a grammar that can be implemented by a common
routine. This means that the grammar can be described in a way that
makes it easy to specify the options via a GUI, if we want to. Also,
since the output of a program is a tree, and the options for a program
are also a tree, we can use one program to control others, in a general
way (that is, not dependent on a specific program's command line option
syntax).
Will this do any good? I believe it will. I believe that there are
many tree filters that can be written that would have wide
application. Just as the text filters in Unix have spawned a style of
programming, I believe that tree filters would expand this to more
problem areas that aren't currently handled well using text files.
(Just as an example, programming language compilers use tree filters.)
Any way, there are a lot of details to work out. If you find this
interesting, and may want to get involved in actually implementing it,
I hope you'll e-mail me.
--
Howard B. Golden
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Drydd" <someone@special>
Subject: Re: UDMA vs IDE: performance comparison wanted
Date: Wed, 15 Sep 1999 14:48:18 -0400
Err... I don't really know how to break this to you, but there aren't
any UDMA hard drives. UDMA stands for Ultra Direct Memory Access and is a
communication method that can be used /on/ EIDE drives... still commonly
referred to as IDE.
IDE/EIDE drives and controllers will either use PIO (programmed I/O
modes) or UDMA to communicate with eachother. If you get a hard drive that
supports UDMA 2, which most do, you'll see significant performance increases
over long file manipulation processes over any of the PIO modes and UDMA 1.
Basicly, what I'm saying is, that you can't compare UDMA vs IDE, since
they go hand in hand. If you want to know whether UDMA is faster than PIO,
yes.
Philip Brown <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> howdy,
>
> I'm wondering if anyone has a chart of IDE vs UDMA performance. Ideally,
> on the same machine using the same controller types, on the same
> RPM speed drives.
>
>
>
> --
> [Trim the no-bots from my address to reply to me by email!]
> [ Do NOT email-CC me on posts. Pick one or the other.]
> http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:@@@D
> The word of the day is mispergitude
------------------------------
From: [EMAIL PROTECTED]
Subject: insmod & printf problem
Date: Wed, 15 Sep 1999 18:47:26 GMT
Hi,
I am writing a kernel module and I am able to compile & link the module
without any problems. But when I do an insmod <module-name>, I get the
following error: "unresolved symbol printk_R1b7d4074".
I have splited the source into 2 files ioctl.c and init_mod.c. I am
using printk in both files and each has a declaration something like
extern printk (const char * fmt, ...); and both include
<linux/kernel.h>.
I am able to do insmod properly when I do the whole stuff in just a
single .c file. Whats going wrong?
nm <module> shows:
U printk
U printk_R11b7d4074
TIA.
Regards,
Murali.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Remco van den Berg)
Subject: Re: unix98 pty's problems
Date: 15 Sep 1999 15:58:09 GMT
On Tue, 14 Sep 1999 22:52:12 GMT, Juergen Heinzl wrote:
>In article <[EMAIL PROTECTED]>,
>Remco van den Berg wrote:
>>On Tue, 14 Sep 1999 20:14:51 GMT, Juergen Heinzl wrote:
>>>
>>>Now telnet (the client) does not care so the daemon will do. Still stay
>>>tuned regarding the official versions, mine is just a tiny hack.
>>>
>>
>>Somebody showed me this site:
>>
>>ftp://ftp.uk.linux.org/pub/linux/Networking/netkit-devel/
>>
>>.. and the telnet daemon there is working out of the box :-)
Just found out that it coredumps on exit. :-(
.. but it _does_ use the unix98 pty's.
>As I am here already, some other programme that can cause trouble
>is ddd and here again, the latest version supports Unix98 PTY's.
Guess what: I'm using that tool also. So have to compile that one
too.
Any more programs?
- Remco van den Berg
============================================================================
Philips Semiconductors B.V. tel:(+31 40 27)22031 fax:22764 Room: BE-345
mailto:[EMAIL PROTECTED] seri: rvdberg@nlsce1
home Email: [EMAIL PROTECTED] (non Philips related) ICQ: 47514668
============================================================================
Microsoft and Lotus Notes free. Don't send me any Microsoft attachments.
============================================================================
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: how to become a linux kernel developer?
Date: Tue, 14 Sep 1999 21:31:39 +0100
Reply-To: [EMAIL PROTECTED]
hoz wrote:
>
> Any advice for a junior level C programmer who wants to get up to
> speed on programming for linux with the goal of working on linux
> kernel development. Other than having a linux system (which
> distribution is best for dev?), the src, and the docs, what else
> should I do?
> ANY suggestions is most appreciated
> /*hoz*/
Familiarise youself with the kernel websites (they can all be found no
more than ~10 clicks away from linux.com).
Browse the kernel mailing list archives every day - when you want to
start active development, subscribe to it.
Write lots of modules that do trivial things with different parts, along
with learning what those parts do (on a course scale).
Familiarise youself with the general logic of the build process.
Try to integrate some of your earlier modules into the tree (keeping the
build process up to date).
Try writing something that's trivial but actually useful to someone and
post the diff to linux-kernel asking for testers - this is where you
start to learn. You'll get some feed back if anyone notices you and what
happens from there on is up to you.
Welcome on board! :)
--
Tristan Wibberley
------------------------------
From: [EMAIL PROTECTED] (Philip Brown)
Subject: Re: UDMA vs IDE: performance comparison wanted
Reply-To: [EMAIL PROTECTED]
Date: 15 Sep 1999 19:29:25 GMT
On Wed, 15 Sep 1999 14:48:18 -0400, someone@special wrote:
> Err... I don't really know how to break this to you, but there aren't
>any UDMA hard drives. UDMA stands for Ultra Direct Memory Access and is a
>communication method that can be used /on/ EIDE drives... still commonly
>referred to as IDE.
Yes yes I know that. It should be clear what I mean already.
"original standard" IDE, vs "IDE plus UDMA extensions".
> IDE/EIDE drives and controllers will either use PIO (programmed I/O
>modes) or UDMA to communicate with eachother. If you get a hard drive that
>supports UDMA 2, which most do, you'll see significant performance increases
>over long file manipulation processes over any of the PIO modes and UDMA 1.
I'm not interested in vague claims of "significant performance increases". I'd
like to see actual figures. Yes, I know it should be faster. I'd like
to know how MUCH faster.
So, once again: Does anyone have any actual data under linux?
--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]
http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:@@@D
The word of the day is mispergitude
------------------------------
From: [EMAIL PROTECTED] (Id Est)
Subject: program/code/advice to find out about unknown keyboard buttons ?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 15 Sep 1999 20:35:51 GMT
there are 4 buttons on the keyboard of this compaq laptop that work under
windoze but not under linux (2.2.9). neither "showkey" nor "xev" sees any
activity from them. does somebody have some idea/code/program that i might
be able to use to determine what irq(s) they use, i/o address(es) they're at,
or any useful information on them at all?
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: Adding XML to Linux (Proposal Outline)
Date: Wed, 15 Sep 1999 02:03:05 +0100
Reply-To: [EMAIL PROTECTED]
"Howard B. Golden" wrote:
>
> (I posted this as a talkback on linuxtoday.com, but I guess here is
> better.)
>
> MS is touting the universal benefits of XML. I totally agree with that
> part of their DNA vapor. Here's how it can really mean something:
[Lots of overview snipped]
Oh God. This is heavy.
I don't think that this can be anywhere within the scope of posix. It is
quite clearly something that is independant of posix, and
cross-platform.
You'll have to implement a prototype before you get much interest - this
will be easy though, since it doesn't require alterations to any
existing software to support this.
For your prototype you can use an init function that parses out a
particular command line option to find the xargs (although I don't think
this is necessary as the xargs can be presented in xstdin). You can get
the names of the FIFOs to use for xstdin and xstdout from the
environment.
Actually I think you can use stdin and stdout all the time, duplicate
the descriptors and create pipes which you parse the real stdin stuff
(from the user) out of the xml input. Now you have a scheme where these
programs can be used on the terminal as the front end because you can
hide the terminal behind a program that wraps the users input within the
xml framework.
A better scheme can be worked out once the uses for this are known
(would it be best to use a simple environment variable to describe the
start of the tree, and that description can be used to find more of the
tree?). You'll need to do quite some more work before you get any real
interest.
--
Tristan Wibberley
------------------------------
From: Markus Jochim <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development.system,alt.os.linux,alt.linux,alt.uu.comp.os.linux.questions,comp.os.linux.development,de.comp.os.linux.misc
Subject: Question: Preventing user processes from interfering with another...
Date: Wed, 15 Sep 1999 15:49:15 +0200
Hello everybody,
I have got a question concerning the mapping from logical to
physical addresses that takes place for example in a Pentium
Processor.
If you take a look at Intels documentation things seem to be
roughly as follows:
A segment selector points to a segment descriptor which gives
you a segment base address. If you add the offset of the
logical address to this base address you gain the linear
address which might be mapped again to a different physical
address if paging is on.
I always thought that the following statement would be true:
Statement A):
"If you want to prevent two different user processes to be able
to access each others memory, then both processes must
be located in different segments. The processor then
enforces boundaries between these segments and insures that one
program does not interfere with the execution of another program
by writing into the other program's segments."
After I took a look into the linux kernel sources I found that,
for example, the code segment selector (cs) for _every_ user program
has the value 0x23. Debugging two identical copies of the same
program at once with gdb showed me, that not only the value
of the cs-register is identical in each instance, but also the
offset-parts of all code adresses are identical.
After taking another look at Intels processor documentation
the only possible explanation that I found is the following:
Statement B):
"As part of a task switch, the processor can also switch to
another LDT, allowing each task to have a different logical-
to-physical address mapping for LDT-based segments. The
page-directory base register (CR3) also is reloaded on a task
switch, allowing each task to have its own set of page tables.
These protection facilities help isolate tasks and prevent them
from interfering with one another. If one or both protection
mechanisms are not used, the processor provides no protection
between tasks. This is true even with operating systems that
use multiple privilege levels for protection. Here, a task
running at privilege level 3 that uses the same LDT and
page tables as other privilege-level-3 tasks can access code
and corrupt data and the stack of other tasks."
Now my questions are the following:
1) Are the two protection mechanisms mentioned in statement B used
by linux?
2) Is the statement A) wrong?
Thanks in advance,
Markus
--
===================================================================
Markus Jochim Raumnummer: 502
Universitaet GH Essen Telefon: 0201 - 183 4092
Fachbereich Informatik
Schuetzenbahn 70
45117 Essen [EMAIL PROTECTED]
(Alle 'x' entfernen um die Mailadresse zu
erhalten)
...und ueberhaupt sieht Perl-Code aus, als haette jemand ein
Guerteltier ueber die Tastatur gerollt!
===================================================================
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Subject: Re: UDMA vs IDE: performance comparison wanted
Date: 15 Sep 1999 17:50:35 -0400
[EMAIL PROTECTED] (Philip Brown) writes:
> I'm not interested in vague claims of "significant performance
> increases". I'd like to see actual figures. Yes, I know it should be
> faster. I'd like to know how MUCH faster.
>
> So, once again: Does anyone have any actual data under linux?
Using a 7200 RPM IBM Deskstar 18 GB, on a Celeron 300A at 450 MHz, PIO
transfer got me about 3-4 MB/sec (with the CPU flat out), and DMA gets
me 13 MB/sec (CPU close to idle). This was using hdparm -t.
The drive is supposed to max out at 17 MB/sec. So I don't really know
for certain if I'm using UDMA (33 MB/sec) or the highest
"conventional" DMA mode (something like 16 MB/sec).
Interestingly, I have to set the drive to a PIO mode in my BIOS for
this to work at all, because otherwise the drive wants to go into
UDMA/66, which doesn't work on my Abit BH6 mobo.
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: [EMAIL PROTECTED] (Dave Platt)
Subject: Re: UDMA vs IDE: performance comparison wanted
Date: Wed, 15 Sep 1999 20:46:15 GMT
In article <[EMAIL PROTECTED]>,
Philip Brown <[EMAIL PROTECTED]> wrote:
>So, once again: Does anyone have any actual data under linux?
I tested out a Quantum Bigfoot drive on my ASUS P5A motherboard at
home, running 2.2.10, with and without the busmaster/UDMA kernel patch
for this motherboard.
The test was a simple one:
dd if=/dev/hda of=/dev/null bs=$((1024*1024)) count=$SOMEBIGNUMBER
The transfer was large enough to greatly exceed the size of physical
memory, thus minimizing the effect of the Linux buffer cache.
When running in PIO mode, the data transfer darned near flatlined the
CPU (a K6-2-300 at the time).
When I switched to DMA mode, the CPU usage dropped to about 5-10%, and
the throughput (bytes per second) almost doubled.
--
Dave Platt [EMAIL PROTECTED]
Visit the Jade Warrior home page: http://www.radagast.org/jade-warrior/
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
------------------------------
From: Uwe Bonnes <[EMAIL PROTECTED]>
Subject: Re: porting unnamed structures
Date: 15 Sep 1999 20:48:22 GMT
Paul J Collins <[EMAIL PROTECTED]> wrote:
:>>>>> "Michael" == Michael Minnick <[EMAIL PROTECTED]> writes:
: --snip--
: Michael> hello.c:4: warning: unnamed struct/union that defines no
: Michael> instances hello.c: In function `main': hello.c:9:
: Michael> structure has no member named `foo'
: --snip--
: AFAIR, that is an extension that Microsoft added. I cannot remember
: the rationale for it. It is logical that it could exist, given that
: C++ has anonymous unions (and I think they will be in the next C
: standard, whatver that one is; I have forgotten the name).
Hallo,
as I understand it, cygwin/ecgs has patches to make ecgs understand those
constructs. Look at http://www.cygnus.com/cygwin
Bye
--
Uwe Bonnes [EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
========= Tel. 06151 162516 ======== Fax. 06151 164321 ==========
------------------------------
** 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
******************************
