Linux-Development-Sys Digest #702, Volume #6 Tue, 11 May 99 22:14:33 EDT
Contents:
Re: DMA from hard drive file, or HD file access from kernal. (Philip Boucherat)
NO_PRO_ID and allocate to CPU in SMP?? (lckun)
Re: Translation of linux to minor languages (Johan Kullstam)
SCO O/S 5 Libs (Tony Scholes)
Re: Translation of linux to minor languages (Andi Kleen)
Anyone have pointers to current Linux for sun3/sun4 machines? (Bob Keys)
Re: Mount multi-track CD ROMs? (Igor Zlatkovic)
Re: Anyone have pointers to current Linux for sun3/sun4 machines? (/dev/niall)
Re: tulip driver woes (was Re: Reliable (!) nic for 2.2 kernel?) (bryan)
Re: tulip driver woes (was Re: Reliable (!) nic for 2.2 kernel?) ("Rinaldi J.
Montessi")
Re: Trouble passing TCP packets through Raw Socket (Dave Koogler)
Re: Glibc rant ("G. Sumner Hayes")
Re: Trouble passing TCP packets through Raw Socket (Andi Kleen)
Re: MCL_FUTURE and mlockall() ("G. Sumner Hayes")
Re: Glibc rant (Thomas Bushnell, BSG)
----------------------------------------------------------------------------
From: Philip Boucherat <[EMAIL PROTECTED]>
Subject: Re: DMA from hard drive file, or HD file access from kernal.
Date: Tue, 11 May 1999 11:20:19 +0100
In article <7gvsnj$6ul$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
writes
>
>I'm reading the O'Reilly book on drivers, but I don't think I will have time
>to finish the book before I need to start this task. Any other tips for
>newbie Linux driver writers in general would also be appreciated.
There is a good article in Linux Journal on DMA and Linux drivers at :
http://www.ssc.com/lj/issue26/interrupt.html.
--
Philip Boucherat
------------------------------
From: lckun <[EMAIL PROTECTED]>
Subject: NO_PRO_ID and allocate to CPU in SMP??
Date: Wed, 12 May 1999 01:46:22 +0900
Hi all!
I am studying for scheduler.
I have got the value 255 for NO_PRO_ID after the debugging with sched.c.
What means the value 255 for NO_PRO_ID??
I have another quation!
I have a computer with 2 cpus.
Is it possible to allocate the processes to one CPU or another CPU in
SMP?
if yes, please help me how can i allocate and/or control the process for
one CPU and another CPU in SMP?
Thanks
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Subject: Re: Translation of linux to minor languages
Date: 11 May 1999 09:43:32 -0400
[EMAIL PROTECTED] (Guest) writes:
> Now, if we had to do it over again, we'd probably use UTF-8 as encoding
> instead of all the different per-country and per-language encodings like SJIS
> and BIG5. I think that's also the way Linux is going: since UTF-8 only uses
> characters above 127 for its multibyte stuff, it won't conflict with special
> characters like '/' in filenames, so you could allow the user to simply use
> UTF-8 for his filenames.
you probably want *both* UTF-8 *and* UTF-16 with a suite of convenient
translators from one to the other. UTF-8 has the advantage of being
fairly compact in memory. UTF-16 has the advantage that each char is
the same size (here it is 16 bits). my feeling is that, as a general
rule, programs will want to UTF-16 internally and files stored on a
disk will be in UTF-8. for example, the getchar and putchar functions
should be configurable to translate automatically.
at this point, i feel it is essential to have some char encoding
metadata with the files so that you know if a particular file is in
us-ascii, iso8859-1, UTF-8, UTF-16 or what have you. the lack of
metadata is imho a failing of the unix filesystem. if would also
allow dispensing with the crock of #!/bin/sh as the first line in a
file since the metadata would contain that information too.
> The only two parts of the system which really need to know about
> this are probably the in- and output, i.e. the input-method to allow
> the user to type special foreign characters (read Japanese) on a
> keyboard that only has a limited number of keys and the
> visualization, i.e. the widget-set or whatever you want to use (so:
> GTK or that library used by KDE).
> > Why should they appear in the UI?
>
> Oh come on ... Never heard of a file-selector or an error message stating this
> or that file was locked or unreadable or corrupt ...
>
> > > - does passwd accepts Japanese or cyrillic characters (or simply say latin
> > > characters, which are not used in English) as password and/or login name?
> > > Ooops, that means cyrillic and Japanese directory names in /home. Can "ls"
> > > deal with them? And can they be found by e.g. a "find -name"?
> Again using UTF-8 would solve part of this without needing to change
> the file-system. The only problem with ls would be that it would
> probably get the column-width wrong when using multi-columns or ls
> -l. The reason being that without modifications ls would assume a
> multibyte UTF-8 encoded string containing 1 character of 3 bytes to
> be 3 characters wide.
isn't this why you would use UTF-16 inside a program?
> It would be nice if strlen could be adapted
> to handle this, but this would break programs that use strlen to
> determine how much memory to allocate for a copy of a string or how
> many bytes should be written to disk. So, I guess some kind of
> UTF8strlen() function should be available and ls and other tools
> that really need to know the width of a string in characters should
> use that instead.
all this machinery could probably be used to bring proportional fonts
into the mix.
> No it won't. ext2 just sees byte-sequences terminated by a
> NUL-byte. How these sequences are interpreted (except for the '/'
> separator) is up to the programs using them. I can use Japanese
> filenames on my 2.0.36 based Linux, but in order to actually see
> them as Japanese, I would need a program turning the UTF-8 encoding
> I use for the filenames into the appropriate glyphs on the screen.
> That step (and the one to enter such strings) should become part of
> the OS (or the libraries) instead of requiring each program to make
> its own implementation. Components without direct user-interaction
> (so no visualization and no user entering data directly into it)
> will not need to know that UTF-8 is used, since they couldn't care
> less whether those 3 bytes represent 3 Latin-1 characters or 1
> foreign character.
yes they would. when the shell expands ? - how many chars is that?
how would sed operate? anything that processes text as text needs to
be able to grok the format.
--
johan kullstam
------------------------------
Date: Tue, 11 May 1999 16:10:56 +0200
From: Tony Scholes <[EMAIL PROTECTED]>
Subject: SCO O/S 5 Libs
Hi
I have a static library of routines in SCO O/S 5 format (COFF I think)
Is there any way I can massage this so that I can link it under Linux
with gcc 2.7.2.3?
I.e. can I extract all the .o's from the lib and cof2elf them or summat?
Any flags to ld?
And no I don't have the source, but I know that if I compile on SCO O/S
5 then the binary runs OK on Linux thanks to IBCS..
TIA
--
Tony Scholes
Technical Manager
===============================================================================
Beacon Computer Services Tel: +44 (0)1582 478888
The Friars, 82 High Street South Fax: +44 (0)1582 478810
Dunstable, Beds. UK Email: [EMAIL PROTECTED]
LU6 3HD Compuserve: 72660,207
===============================================================================
------------------------------
Subject: Re: Translation of linux to minor languages
From: Andi Kleen <[EMAIL PROTECTED]>
Date: 11 May 1999 16:38:30 +0200
[EMAIL PROTECTED] (Jonathan A. Buzzard) writes:
>
> I can see that a user might want to use non latin characters in a file name,
> but I don't think that ext2 supports Unicode file names, so this is a
> moot point currently. It will however take a massive effort to get
> working.
ext2 supports UTF-8 like most other things in the kernel.
The Linux console driver does too with an appropiate code page.
The ISO9660 FS knows how to translate various national character
sets into UTF-8.
-Andi
--
This is like TV. I don't like TV.
------------------------------
From: [EMAIL PROTECTED] (Bob Keys)
Subject: Anyone have pointers to current Linux for sun3/sun4 machines?
Date: 11 May 1999 14:43:39 GMT
I was thinking of trying a Linux on some of my old sun3/sun4 machines
(not sun4c or later architecture).
Anyone have a pointer to those working on ports for those early sun
machines?
Thanks
Bob Keys
------------------------------
From: Igor Zlatkovic <[EMAIL PROTECTED]>
Subject: Re: Mount multi-track CD ROMs?
Date: Tue, 11 May 1999 16:06:43 +0000
Keith Wright wrote:
> Is this 2.0.36 or 2.2 you are talking about. And _how_ do you see the
> other session? When I mount the CD it gets the first session, is there
> an option to get the others?
It is 2.2.x. I don't remember if the option existed in 2.0.x kernels.
You cannot mount different sessions. What should happen is see all the data
written across multiple sessions after mounting a CD. I'm not an expert in this
field, so I cannot tell you much more. Just try to compile an 2.2.x kernel with
the option enabled and look what happens. If the prob is gone, you know where to
direct further investigation.
--
o
O Cheers,
______O___
\________/ Igor Zlatkovic
\ o / mailto:[EMAIL PROTECTED]
\ O /
\ /
\/
|| University of Applied Sciences
___||___ Frankfurt, Germany, EU.
------------------------------
From: /dev/niall <[EMAIL PROTECTED]>
Subject: Re: Anyone have pointers to current Linux for sun3/sun4 machines?
Date: Tue, 11 May 1999 22:21:26 GMT
Try http://www.ultralinux.org
> I was thinking of trying a Linux on some of my old sun3/sun4 machines
> (not sun4c or later architecture).
>
> Anyone have a pointer to those working on ports for those early sun
> machines?
--
--
/dev/niall
http://www.kst.com/knownspace/
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: bryan <[EMAIL PROTECTED]>
Subject: Re: tulip driver woes (was Re: Reliable (!) nic for 2.2 kernel?)
Crossposted-To: comp.os.linux.networking
Date: Tue, 11 May 1999 23:34:56 GMT
In comp.os.linux.networking Ronald Cole <[EMAIL PROTECTED]> wrote:
: bryan <[EMAIL PROTECTED]> writes:
: > I don't necessarily need the -latest- driver, just the most stable in
: > the 2.2 world. in 2.0.36, things were great.
: No, they weren't. I'm running linux-2.0.36 on my 486 firewall with
: two Kingston (tulip) PCI NICs and the net hangs on that machine quite
: often.
maybe a slow host?
maybe my new host is TOO fast? (dual 450 celerons).
: It requires me to go to the console, bring down eth0, bring it
: back up, and re-add the route before things work again.
different hang than I have. my hang CANNOT be undone by anything
short of a full system reset. maybe the bus is hanging? pci
problems? shutting the net down and back up again never helps the
hangs that I have.
: > now they're not so great. what happened in-between?
: linux-2.0.36 has tulip-0.89H and linux-2.2.7 has tulip-0.89H.
: You tell me!
wow - I didn't go so far as to check. strange! I know that I ran a
whole netmgt setup at my old job (large campus network, 25 buildings,
lotsa lans) with a linux box and 2.0.36 - and there was never an
ethernet problem. I could do a back-to-back ping till the cows came
home and never a problem.
--
Bryan
------------------------------
From: "Rinaldi J. Montessi" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: Re: tulip driver woes (was Re: Reliable (!) nic for 2.2 kernel?)
Date: Tue, 11 May 1999 19:44:40 -0400
Ronald Cole spake:
> bryan <[EMAIL PROTECTED]> writes:
> > I don't necessarily need the -latest- driver, just the most stable in
> > the 2.2 world. in 2.0.36, things were great.
>
> No, they weren't. I'm running linux-2.0.36 on my 486 firewall with
> two Kingston (tulip) PCI NICs and the net hangs on that machine quite
> often. It requires me to go to the console, bring down eth0, bring it
> back up, and re-add the route before things work again.
>
> > now they're not so great. what happened in-between?
>
> linux-2.0.36 has tulip-0.89H and linux-2.2.7 has tulip-0.89H.
> You tell me!
>
> --
> Forte International, P.O. Box 1412, Ridgecrest, CA 93556-1412
> Ronald Cole <[EMAIL PROTECTED]> Phone: (760) 499-9142
> President, CEO Fax: (760) 499-9152
> My PGP fingerprint: 15 6E C7 91 5F AF 17 C4 24 93 CB 6B EB 38 B5 E5
tulip.c version 0.91 is available
http://cesdis.gsfc.nasa.gov/linux/drivers/tulip.html
--
Rinaldi -
Sometimes a cigar is merely a cigar. Sigmund Freud
Visit the crew at:
snews://secnews.netscape.com/netscape.test.multimedia
------------------------------
From: Dave Koogler <[EMAIL PROTECTED]>
Subject: Re: Trouble passing TCP packets through Raw Socket
Date: Tue, 11 May 1999 14:26:43 -0400
Reply-To: [EMAIL PROTECTED]
Andi Kleen wrote:
> First this looks hackish. For general purpose packet insertion
> you would probably use a SOCK_PACKET socket though (which operates
> at layer2 only), instead of doing all that special purpose code.
> You would inject it to a dummy interface.
Yes, the raw socket approach is crude. Since I am working from
ignorance, I am leaning heavily on published information such as
Steven's "Unix Network Programming" and Rubini's "Linux Device
Drivers". Steven's discusses raw sockets in great depth, but only for
ICMP and UDP.
SOCK_PACKET seems to be a Linux-ism and I have not found any description
of this socket type (the 'socket' man page just mentions its existance
and says nothing about how it acts). Where is there a description of
this mechanism?
> Linux 2.2 also has a special purpose device for this application: > ethertap.
Alas, I must stay with the 2.0.xx series. My code is part of a much
larger system and the company has fixed on 2.0.xx as the delivery
vehicle.
>> ICMP and UDP messages work fine. TCP messages fail, but in a rather
>> unusual way. It appears that the raw socket passes the IP and TCP
>> headers, but with the IP total length set as just the size of the
>> two headers without the data. But the incoming packet does have
>data.
>
> Does this happen on sending or receiving?
Sending data. According to Steven's, you can not have a raw socket for
reading TCP, only for writing.
> Could you post a small test program for that? (that would clear the
> ambiguities)
Here is the offending code. 'packet' is the incoming data packet with
a prepended Cisco header. (I have removed my debugging statements so
you can easily see the code).
void
relay_tcp_pkt (unsigned char *packet, int packet_length)
{
int on, result;
struct iphdr *ip;
struct tcphdr *tcp;
/* Strip off the cisco header. */
packet = packet + sizeof (struct cisco_hdr);
packet_length = packet_length - sizeof (struct cisco_hdr);
ip = (struct iphdr *) packet;
tcp = (struct tcphdr *) (packet + (ip->ihl * 4));
sockaddr.sin_family = AF_INET;
sockaddr.sin_port = tcp->dest;
sockaddr.sin_addr.s_addr = ip->daddr;
if (TCP_sock == 0) {
TCP_sock = socket (AF_INET, SOCK_RAW, IPPROTO_TCP);
if (TCP_sock < 0) {
if (errno == EPERM)
printf ("Must run as root\n");
else
perror ("Opening TCP socket");
exit (-1);
}
on = 1;
if (setsockopt (TCP_sock, IPPROTO_IP, IP_HDRINCL,
&on, sizeof (on)) < 0) {
perror ("Setting TCP socket options");
exit (-1);
}
}
result = sendto (TCP_sock, packet, packet_length, 0,
&sockaddr, sizeof (struct sockaddr));
if (result < 0) {
perror ("Error relaying TCP packet");
}
}
With a debugger, I can see the packet is correctly formed upto the
'sendto' and the packet_length is correct. When I look at the packet
comming back through my device driver, I see the mysteriously shortened
packet with no data, but properly formed IP and TCP headers.
> Does 2.2 show the same thing?
I will try building a 2.2.xx kernel and see what happens. I also have
access to a Sun system to see how it's raw sockets behave.
Dave Koogler
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss
Subject: Re: Glibc rant
Date: Tue, 11 May 1999 14:55:09 -0400
I'm adding gnu.misc.discuss in an effort to get some feedback to the
people who are in charge of glibc. I'm unsure about whether or not
I should CC: Ulrich, as this is a large ongoing thread and likely to
fill his mailbox with pointless posts.
Background: On comp.os.linux.development.system, there's a big thread
on the backward compatibility issues between glibc versions 2.0 and
2.1. Binary compatibility is getting to be more and more important
in the Linux world; even when only free software is used, a lot of
users don't build it themselves. There are also issues in heterogenous
NFS-mount environments, etc.
The hope is that distribution packages like Red Hat and Debian can
release new versions that are 100% downward compatible with old
versions. Obviously the symbol versioning in glibc was introduced to
help cope with this sort of thing; it may also be necessary to bump the
major version every couple of years when a truly incompatible change
is introduced. The goal, though, is for people who use old binaries
to be able to continue doing so -- if you have to have a couple of
major versions of the C library to run 10 year old binaries, that's
fine.
In this particular instance, people on c.o.l.d.s have had problems
with the transition to the latest releases of Debian and Red Hat
(glibc 2.0 to glibc 2.1) and binary compatibility. The questions are:
1. Is there a good way to avoid these problems that the distribution
packagers overlooked? Would, e.g., installing glibc 2.1.0 along with
glibc 2.0.6 (or 2.0.7pre?) allow the old glibc-2.0 linked (possibly
linked against ncurses, etc) to continue running? Is there some
compatibility library that could be installed? If so, how can the
glibc folk and distributions communicate better in the future so that
this sort of solution is understood by the appropriate parties and
deployed?
2. If not, why not? It had been my contention that glibc-2.0 was
never a fully stable release -- the FAQ, announcement, and READMEs at
www.gnu.org all indicate that it is something to the effect of a
wide-release beta version. If that's the case, then ABI changes are
to be expected. The excerpt at the end of this post casts a bit of
doubt on that theory, unfortunately.
3. To what extent will a transition from past FSF-developed versions
of gcc to future egcs steering commitee versions affect this? It seems
well documented that C++ binary compatibility will break hard in the
not-to-distant future; that seems reasonable given that it is so well
documented. What about C?
In short, what's the best way to go about ensuring binary compatibility
in the future? What do the distribution packagers need to do to help
out? What does the Linux community need to do to help out? What are
the glibc people doing along these lines?
Joel Klecker wrote:
> >[SNIP: glibc-2.0 was a development release according to announce,
> >README, FAQ]
> The documentation may have claimed it, but that did not stop glibc
> developers from recommending that the dists use it.
> In January 1997, Ulrich Drepper suggested that Debian "base any future
> releases on [glibc 2.0]."
That's a real problem, IMO. When Ulrich makes a statement like that,
it's tantamount to saying that this is a stable release; in that case,
backward compatibility of future releases with the same major version
number is a major deal, IMO.
What can be done?
--Sumner
------------------------------
Subject: Re: Trouble passing TCP packets through Raw Socket
From: Andi Kleen <[EMAIL PROTECTED]>
Date: 11 May 1999 21:07:10 +0200
Dave Koogler <[EMAIL PROTECTED]> writes:
> Andi Kleen wrote:
>
> > First this looks hackish. For general purpose packet insertion
> > you would probably use a SOCK_PACKET socket though (which operates
> > at layer2 only), instead of doing all that special purpose code.
> > You would inject it to a dummy interface.
>
> Yes, the raw socket approach is crude. Since I am working from
> ignorance, I am leaning heavily on published information such as
> Steven's "Unix Network Programming" and Rubini's "Linux Device
> Drivers". Steven's discusses raw sockets in great depth, but only for
> ICMP and UDP.
>
> SOCK_PACKET seems to be a Linux-ism and I have not found any description
> of this socket type (the 'socket' man page just mentions its existance
> and says nothing about how it acts). Where is there a description of
> this mechanism?
ftp.firstfloor.org:/pub/ak/netman* contains packet.7, which has a description
of the Linux 2.2 version of it (PF_PACKET). SOCK_PACKET is a slightly more
primitive version of PF_PACKET. Note that netman is still alpha and not finished.
I heard that the new edition of Steven's UNP contains a description of
the 2.0 SOCK_PACKET, although I cannot state how accurate it is because
I have not seen it.
If you need portability you should write for the libpcap library, which
hides the system specifics and is ported to a wide number of Unix systems.
On other systems your RAW sockets approach for injecting packets would
most likely not work.
The main problem with your raw sockets approach is that you only handle IP,
and with your approach only TCP,UDP,ICMP (although you could use IPPROTO_RAW
to catch all IP protocols at least)
I would suggest using SOCK_PACKET on a dummy device. There are other ways
(e.g. Alan Cox has successfully used a SLIP link over a pty), but these
are too hackish I would think.
>
> > Linux 2.2 also has a special purpose device for this application: > ethertap.
>
> Alas, I must stay with the 2.0.xx series. My code is part of a much
> larger system and the company has fixed on 2.0.xx as the delivery
> vehicle.
>
> >> ICMP and UDP messages work fine. TCP messages fail, but in a rather
> >> unusual way. It appears that the raw socket passes the IP and TCP
> >> headers, but with the IP total length set as just the size of the
> >> two headers without the data. But the incoming packet does have
> >data.
> >
> > Does this happen on sending or receiving?
>
> Sending data. According to Steven's, you can not have a raw socket for
> reading TCP, only for writing.
That does not apply to Linux. The raw.7 manpage in netman* explains it.
Stevens is a BSD guy @)
> > Does 2.2 show the same thing?
>
> I will try building a 2.2.xx kernel and see what happens. I also have
> access to a Sun system to see how it's raw sockets behave.
Differently definitely.
-A.
--
This is like TV. I don't like TV.
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: MCL_FUTURE and mlockall()
Date: Tue, 11 May 1999 15:13:16 -0400
"Vladimir G. Stanishev" wrote:
>
> this first question is about mlockall() and the MCL_FUTURE parameter.
> [SNIP]
> How is mlockall() implemented in Linux, is it a "nice" or a nasty
> system?
man pages are your friend.
Here's an excerpt from the mlockall man page. "man mlockall" for
more info:
If MCL_FUTURE has been specified and the number of locked
pages exceeds the upper limit of allowed locked pages,
then the system call which caused the new mapping will
fail with ENOMEM. If these new pages have been mapped by
the the growing stack, then the kernel will deny stack
expansion and send a SIGSEGV.
Which seems "nice" by your definition (growing the stack has no
return value, so it can't return failure).
--Sumner
------------------------------
From: [EMAIL PROTECTED] (Thomas Bushnell, BSG)
Crossposted-To: gnu.misc.discuss
Subject: Re: Glibc rant
Date: 11 May 1999 21:58:58 -0400
It is not at all unreasonable for shared libraries to occasionally
have to bump the soname. That does not require "every application to
be rebuilt", it requires people to have both versions of the library
on disk.
It is not uncommon at all for commercial Unix distributions to change
the soname periodically from release te release. Third-party add-on
software gets certified for particular versions of Solaris or Irix or
whatever, and it's a happy thing when it works on other versions, but
not automatically expected.
It's ridiculous to think that there should be a ten-year gap between
soname bumps. The gap between the release of glibc 2.0 and the
release of 2.1 was over two years, IIRC, and that just doesn't seem
bad at all.
Some people think the major version number is relevant here; they
misunderstand. The relevant thing is the soname, which needs to be
bumped when an incompatible interface change is made. There is no
implication anywhere in glibc that soname changes only happen with
major version number changes.
Thomas
------------------------------
** 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
******************************
