Linux-Development-Sys Digest #701, Volume #7 Thu, 23 Mar 00 13:13:28 EST
Contents:
Re: Absolute failure of Linux dead ahead? (Dale Pontius)
Kernel Implementation Languages (Christopher Browne)
Re: poll()ing TCP sockets - when can I expect a POLLHUP? (Andi Kleen)
Re: UART overrun errors (Johan Kullstam)
physical and virtual addresses and ioremap (Mathias Waack)
Re: poll()ing TCP sockets - when can I expect a POLLHUP? (Casper H.S. Dik - Network
Security Engineer)
Re: UART overrun errors (Mats Byggmastar)
Re: Problem getting mmap region to work correctly.... Please help... (Robert Nickel)
Re: Zero padding in sprintf() doesn't work for strings - HELP ! (Wolfram Gloger)
Re: Problem getting mmap region to work correctly.... Please help... (Anders Larsen)
Re: Absolute failure of Linux dead ahead? (Mario Klebsch)
Re: Absolute failure of Linux dead ahead? (Kaz Kylheku)
Re: Driver? ("Shawn Halwes")
Re: Zero padding in sprintf() doesn't work for strings - HELP ! ("Fred Jackson")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Dale Pontius)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: 23 Mar 2000 14:23:23 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Christopher Browne) writes:
...
> If you avoid those issues, you are still likely to jump onto the horns
> of "problem d):"
>
> a)-c) aren't defined in a formally standardized way that can be
> considered portable.
How about Ada?
There's even a GPL Ada compiler available, GNAT. (not the firewall)
Take a look over on comp.lang.ada for more.
I know none of this language shift will likely ever happen. To go
from a model much different from C, you'd have to spend a LONG time
reimplementing - time that might well be better spent supporting new
hardware or new features. About the only way any alternate language
could be introduced into the kernel is if it 'played well with C',
and could be used to implement new features or new hardware support.
Then, as language bigots had time, they could reimplement existing
features.
But truly, it seems like more pain than it's worth.
Dale Pontius
NOT speaking for IBM
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.advocacy
Subject: Kernel Implementation Languages
Reply-To: [EMAIL PROTECTED]
Date: Thu, 23 Mar 2000 14:42:28 GMT
Centuries ago, Nostradamus foresaw a time when Dale Pontius would say:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Christopher Browne) writes:
>...
>> If you avoid those issues, you are still likely to jump onto the horns
>> of "problem d):"
>>
>> a)-c) aren't defined in a formally standardized way that can be
>> considered portable.
>
>How about Ada?
Ada != Pascal.
My criticisms were very specific to Pascal, and are not applicable
to Modula-2, Oberon, Ada, or Modula-3, all "Wirth-inspired" languages
which *do* offer more than does Pascal.
>There's even a GPL Ada compiler available, GNAT. (not the firewall)
>Take a look over on comp.lang.ada for more.
Also not the same as GNATS, the bug tracker...
>I know none of this language shift will likely ever happen. To go
>from a model much different from C, you'd have to spend a LONG time
>reimplementing - time that might well be better spent supporting new
>hardware or new features. About the only way any alternate language
>could be introduced into the kernel is if it 'played well with C',
>and could be used to implement new features or new hardware support.
>Then, as language bigots had time, they could reimplement existing
>features.
>
>But truly, it seems like more pain than it's worth.
The problem is that even with something as intentionally similar to
C as C++, it's problematic to "play well with C" and actually make
use of the extended features of the language.
Your comments above represent decent pragmatic reasons to not bother
with the reimplementation. It would take a lot of work just to regain
what Linux does *now* in another language.
What's likely to be prohibitively discouraging to such a project is
the fact that there are such an immense number of device drivers
written in C for Linux and *BSD. People trying to build other OS
kernels [Hurd and OSKit leap to mind] wind up designing their systems
so they can take advantage of Linux and FreeBSD device drivers.
Write a kernel in Modula-3 that doesn't basically head to LCD of having a
C-dependent base and you'll have to recreate from scratch device drivers
for every kind of device you ever want to use.
The body of device drivers is the main strength that Linux has over
nearly all its possible competitors, which actually may include W2K,
to some extent...
--
Rules of the Evil Overlord #16. "One of my advisors will be an average
five-year-old child. Any flaws in my plan that he is able to spot will
be corrected before implementation."
<http://www.eviloverlord.com/lists/overlord.html>
[EMAIL PROTECTED] - - <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: Re: poll()ing TCP sockets - when can I expect a POLLHUP?
Date: 23 Mar 2000 16:22:08 +0100
[EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer) writes:
> >Single Unix does not require it:
>
> > POLLIN
> > Data other than high-priority data may be read without
> > blocking. For STREAMS, this flag is set in revents even if the
> > message is of zero length.
>
> I'm referrng to setting POLLHUP, that is a bug (if the local
> end isn't closed)
It is only set when the local end point is closed.
-Andi
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Subject: Re: UART overrun errors
Date: 23 Mar 2000 09:30:38 -0500
Mats Byggmastar <[EMAIL PROTECTED]> writes:
> Johan Kullstam wrote:
> > > >
> > > >Does this mean that the interrupt that the 16550A issues isn't served by
> > > >the driver in time and the FIFO gets overwritten?
> > > >
> > > A couple of things:
> > >
> > > - the UART generates an interrupt when data is ready...
> > > (Possibly, when there are certain number of bytes in
> > > its FIFO buffer)...the OS prioritizes the interrupts
> > > so a DISK interrupt may have priority over a serial port
> > > interrupt... but we can't control that...
> >
> > oh yes we can. irqtune.
>
> irqtune ?
>
> Is that some kernel internal stuff or can it be accessed from
> user space?
it's both. irqtune is actually a kernel module with a wrapper. you
run it in userspace (as root of course) and the script inserts the
irqtune module which then rearranges interrupt priorities. then the
module is removed but the priorities remain. please see the irqtune
website. it's quite informative.
<URL:http://www.best.com/~cae/irqtune/>
--
johan kullstam l72t00052
------------------------------
From: Mathias Waack <[EMAIL PROTECTED]>
Subject: physical and virtual addresses and ioremap
Date: Thu, 23 Mar 2000 16:14:03 +0100
Hi all,
I've got a question about the address mapping (I'm using kernel 2.2.14).
Because I've got no device I could play with, I've booted linux with
the parameter mem=200M.
After that I loaded a kernel module doing the following:
char* virt = ioremap(0xC800000, 0x3800000);
printk("%lx %lx %lx\n",0xC800000,phys_to_virt(0xC800000), bus_to_virt(0xC800000));
printk("%lx %lx %lx\n",virt,virt_to_phys(virt),virt_to_bus(virt);
just to check my understanding. I've got the output:
c800000 cc800000 cc800000
cd05d000 d05d000 d05d000
The first row is what I expected, but I don't understand the second.
>From my understand the second value of the first row and first value
of the second row should be the same. And the first value of first row
and the second value of the second row should also be the same.
After that I've used the addresses from ioremap the mmap this memory
to the user space:
ptr = virt + some_offset;
remap_page_range( vma->vm_start, virt_to_phys(virt), some_bytes, vma->page_prot)
This seems to fail, the system becomes instable because the memory seems to become
corrupted.
So where is my failure?
Mathias
------------------------------
From: [EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer)
Crossposted-To: comp.unix.programmer
Subject: Re: poll()ing TCP sockets - when can I expect a POLLHUP?
Date: 23 Mar 2000 15:07:04 GMT
[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
Andi Kleen <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer) writes:
>> >Single Unix does not require it:
>>
>> > POLLIN
>> > Data other than high-priority data may be read without
>> > blocking. For STREAMS, this flag is set in revents even if the
>> > message is of zero length.
>>
>> I'm referrng to setting POLLHUP, that is a bug (if the local
>> end isn't closed)
>It is only set when the local end point is closed.
I.e, when a half-close is done a filedescriptor that is subsequently polled
and the other end has send a FIN?
If you're talking about a loopback connection where the other end has done a
close, I maintain it is still in error to signal POLLHUP
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: Mats Byggmastar <[EMAIL PROTECTED]>
Subject: Re: UART overrun errors
Date: Thu, 23 Mar 2000 17:01:21 +0100
Etienne Lorrain wrote:
> In short, use "hdparm" to enable interrupts when tranfering data
> to/from HD, in your rc scripts.
Thanks!
>From the hdparm man page:
-u Get/set interrupt-unmask flag for the drive. A setting of 1
permits the driver to unmask other interrupts during
processing of a disk interrupt, which greatly improves Linux's
responsiveness and eliminates "serial port overrun" errors.
:-)
I tested it and it seems to work fine. Running updatedb and firing
up netscape at the same time did not interfere with my serial traffic.
Only when switching from X Windows to console mode (CTRL-ALT-F*) I got
some overrun errors. I guess this is the same problem but it is not
as critical for my application.
Mats
------------------------------
From: Robert Nickel <[EMAIL PROTECTED]>
Subject: Re: Problem getting mmap region to work correctly.... Please help...
Date: Thu, 23 Mar 2000 08:36:35 -0800
In article <[EMAIL PROTECTED]>, Anders Larsen
<[EMAIL PROTECTED]> wrote:
> Robert Nickel wrote:
>>
>> I'm trying to write a user space loader program that loads control rom
>> from a disk file into volatile rom on the card. This is done via i/o
>> ports and the memory range from 0xd0000-0xd7fff.
>>
>> The i/o ports part was really simple and I've got it under control.
>> The part that's keeping me up nights is the mmap portion. I can't get
>> it to work for me, and I'm curious as to why.
>>
>> The card is supposed to switch 16k banks of the memory to and from the
>> beginning of the memory range. The problem I'm having is that the
>> banks aren't switching. I'm wondering if it is the MAP_PRIVATE flag in
>> my call to mmap.
>>
>> Here's my code, boiled down to the part that is giving me grief:
>>
>> --------------------------------------------------
>>
>> //The variables in question are defined as follows
>> unsigned char *cardmem; int memptr;
>>
>> if ((memptr=open("/dev/mem", O_RDWR))<0) {
>> choke_and_die("Couldn't get memory"); //My death function
>> exit(1);
>> }
>>
>> if ((cardmem=(unsigned char *)
>> mmap(0,0x7fff,PROT_READ|PROT_WRITE,MAP_PRIVATE,0xd0000))<0) {
>> choke_and_die("Couldn't map memory"); exit(1);
>> }
>>
>> *cardmem=0xf3;
>>
>> //outb to switch banks
>>
>> *cardmem=0xff;
>>
>> //outb to switch banks back to original
>>
>> if (*cardmem!=0xf3) {
>> choke_and_die("Memory banks didn't switch"); exit(1);
>> }
>>
>> -----------------------------------------------------------------------------
>>
>> That's it. It always dies on switching the banks.
>
> Could you change the line *cardmem=0xff; to write another value and then
> see what you get back in your test, that is, check if you can write to
> the memory at all? My guess is you can, otherwise your task would
> probably have been killed; that is, the memory is indeed mapped. Are you
> 100% sure your bank-switching outb are correct?
>
> BTW, the 2.nd parameter to mmap (length) should be 0x8000, not 0x7fff.
>
> --
> Anders Larsen
Yes, I did do more boiling down that I should've. I got it to work last night and
just about jumped off
my chair I was so happy. Anyway, here's a correct snippet (I hope) of what I did.
Thanks to all for the help - I'm sure that I'll be needing more in the future.
--Robert
==========Begin snippet================
//The variables in question are defined as follows
volatile unsigned char *cardmem; int memptr;
if ((memptr=open("/dev/mem", O_RDWR))<0) {
choke_and_die("Couldn't get memory"); //My death function
exit(1);
}
//Come to find out, I only needed to access the bottom 16k of the card address, so the
length value
//is now 0x4000 - an even page amount.
//Also changed the flags to MAP_SHARED from MAP_PRIVATE.
if ((cardmem=(unsigned char *)
mmap(0,0x4000,PROT_READ|PROT_WRITE,MAP_SHARED,memptr,0xd0000))<0) {
choke_and_die("Couldn't map memory"); exit(1);
}
*cardmem=0xf3;
//outb to switch banks
//Had to put in a delay here to let the card clunk it's way around. I used sleep,
which is bad, but it works and this
//program is a fire and forget to load executable code to the cards rom and doesn't
need to be elegant.
*cardmem=0xff;
//outb to switch banks back to original
//again, put in delay with sleep.
if (*cardmem!=0xf3) {
choke_and_die("Memory banks didn't switch"); exit(1);
}
.
.
.
munmap(cardmem,0x4000);
close(memptr);
==========End snippet================
------------------------------
From: Wolfram Gloger <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Zero padding in sprintf() doesn't work for strings - HELP !
Date: 23 Mar 2000 16:13:23 +0100
Gerd Buesken <[EMAIL PROTECTED]> writes:
> Regarding sprintf, the man pages say:
> 0 specifying zero padding. For all conversions except n, the
> converted value is padded on the left with zeros rather than blanks.
> If a precision is given with a numeric conversion (d, i, o, u, i, x,
> and X), the 0 flag is ignored.
The man page is wrong (I'll try to get it fixed). From the C standard
7.19.6.1:
0 For d, i, o, u, x, X, a, A, e, E, f, F, g, and G
conversions, leading zeros (following any indication
of sign or base) are used to pad to the field width |
rather than performing space padding, except when |
converting an infinity or NaN. If the 0 and - flags
both appear, the 0 flag is ignored. For d, i, o, u,
x, and X conversions, if a precision is specified, the
0 flag is ignored. For other conversions, the
behavior is undefined.
Therefore, the following piece of code
> sprintf (buff,"%06s", LenBuf);
invokes undefined behaviour.
> It seems as if the output on Linux is wrong(using Blanks instead of zeros).
No, it could also just crash or print `bug-bug!' and exit.
Regards,
Wolfram.
------------------------------
From: Anders Larsen <[EMAIL PROTECTED]>
Subject: Re: Problem getting mmap region to work correctly.... Please help...
Date: Thu, 23 Mar 2000 17:51:32 +0100
Robert Nickel wrote:
[snip]
> Yes, I did do more boiling down that I should've.
> I got it to work last night and just about jumped off my chair
> I was so happy. Anyway, here's a correct snippet (I hope) of what I did.
>
> Thanks to all for the help - I'm sure that I'll be needing more in the future.
Congratulations!
> ----------Begin snippet----------------
[snip]
> //outb to switch banks
> //Had to put in a delay here to let the card clunk it's way around.
> // I used sleep, which is bad, but it works and this
> //program is a fire and forget to load executable code to the cards
> // rom and doesn't need to be elegant.
[snip]
> ----------End snippet----------------
You can abuse select() to do a fairly portable sub-second sleep.
$ man 2 select
Cheers
Anders Larsen
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Thu, 23 Mar 2000 17:32:40 +0100
[EMAIL PROTECTED] (Christopher Browne) writes:
>The problem with Pascal, as distinct from the others, is that the
>design just wasn't made for anything more than education.
>a) It defines a single pass compiler;
I have used a two pass pascal compiler for several years (Pascal-MT).
>b) It provides no way of splitting projects coherently into multiple
> files;
With the UCSD-Pascal system, you project could be splitted into
several units, Each unit had its own source file.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 23 Mar 2000 17:43:57 GMT
On Thu, 23 Mar 2000 05:27:45 GMT, Christopher Browne
<[EMAIL PROTECTED]> wrote:
>Centuries ago, Nostradamus foresaw a time when The Ghost In The
>Machine would say:
>>In comp.os.linux.advocacy, SetMeUp <[EMAIL PROTECTED]>
>>wrote on Wed, 22 Mar 2000 19:43:06 GMT
>><en9C4.1872$[EMAIL PROTECTED]>:
>>>> What's wrong with Modula-3? ;)
>>>
>>> It's wrong that it is not C.
>>
>>Hmm..."Not C"...um...is that close enough to Godwinize this thread? :-)
>>
>>Mind you, I do know at least two operating systems (Apollo/DOMAIN Aegis
>>and older versions of MacOS) which were written in Pascal, or some
>>variant thereof, so I guess it could work... :-)
>
>The problem with Pascal, as distinct from the others, is that the
>design just wasn't made for anything more than education.
>
>a) It defines a single pass compiler;
But C was also designed to require only a single pass compiler (if we ignore,
for a minute, the preprocessing stages that were added later). If anything,
this is a virtue rather than a vice. A practical language is meant to get
software development done, not to stroke the egos of compiler designers.
--
#exclude <windows.h>
------------------------------
From: "Shawn Halwes" <[EMAIL PROTECTED]>
Subject: Re: Driver?
Date: Thu, 23 Mar 2000 11:49:03 -0600
I tried all the standard SCSI cdrom drivers that came with the Red Hat
(Cartman) relaease...
Shawn
"Grant Edwards" <grant@nowhere.> wrote in message
news:[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>, Shawn Halwes wrote:
>
> >Anyone know where I can find a driver for a NEC SCSI CD-ROM that uses a
NEC
> >462 Windows driver?
>
> The standard SCSI cdrom driver should work fine. Have you
> tried it?
>
> --
> Grant Edwards grante Yow! My mind is making
> at ashtrays in Dayton...
> visi.com
------------------------------
From: "Fred Jackson" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Zero padding in sprintf() doesn't work for strings - HELP !
Date: Thu, 23 Mar 2000 12:50:46 -0500
It is very, very unusual to use the zero padding
modifier with a string conversion (%s). I don't
think I've ever run into this usage. It scarcely
makes any sense. Not a flame, but this is very
unusual usage.
Gerd Buesken <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi
>
> I have a problem using gcc 2.95 running on a 2.2.5-15 Red Hat linux.
>
> Regarding sprintf, the man pages say:
> 0 specifying zero padding. For all conversions except n, the
> converted value is padded on the left with zeros rather than blanks.
> If a precision is given with a numeric conversion (d, i, o, u, i, x,
> and X), the 0 flag is ignored.
>
> My source looks like this:
>
> include <stdio.h>
>
> main()
> {
> char buff[30];
> char LenBuf[30];
>
> strcpy(LenBuf,"1");
> sprintf (buff,"%06s", LenBuf);
> printf( "buffer=%s; Length %06d\n",buff, strlen(LenBuf) );
> }
>
> This is the Linux output:
> buffer= 1; Length 000001
>
> This is the HP-UX output:
> buffer=000001; Length 000001
>
> It seems as if the output on Linux is wrong(using Blanks instead of
zeros).
>
> Does anybody has a solution other than rewriting the code ?
>
> Thanks
> Gerd
------------------------------
** 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
******************************
