Linux-Development-Sys Digest #723, Volume #7 Fri, 31 Mar 00 19:13:15 EST
Contents:
Re: Starting Linux Kernel Programming (John Gluck)
Re: Zero padding in sprintf() doesn't work for strings - HELP ! (Stephen Harris)
Re: Hard disk DMA access, SMP bug? (John Gluck)
Re: Precision of Linux's libm??? ([EMAIL PROTECTED])
RFD: comp.os.linux.embedded (John Peterson)
interruptible_sleep_on() problem... (Badrinath Venkatachari)
Increasing # of semaphores in semaphore set? (DHodson)
Re: Precision of Linux's libm??? (Johan Kullstam)
Re: Compile IMG (Victor Wagner)
Re: Precision of Linux's libm??? (Harlan Grove)
----------------------------------------------------------------------------
From: John Gluck <[EMAIL PROTECTED]>
Subject: Re: Starting Linux Kernel Programming
Date: Fri, 31 Mar 2000 13:07:47 -0500
dave nejdl wrote:
>
> I am a long time c programmer and linux user. I recently decided to get
> into understanding and programming in the linux kernel, especially
> writing device drivers. But I'm having trouble finding resources. The
> Linux Kernel at linuxdoc.org was an excelent read, but I'm looking for a
> resource that is more focused on "programming" in the kernel(kernel
> functions and such). I may buy these two books:
> -Linux Kernel Internals
> -Linux Device Drivers (nutshell handbook)
>
> I'd greatly appreciate other resources or suggestions anyone could
> offer.
>
> Thank you,
> Dave Nejdl
I have the Linux Kernel Internals book and it's pretty good but remember
that many things change from version to version (IE 2.0.xx to 2.2.xx).
--
John Gluck (Passport Kernel Design Group)
(613) 765-8392 ESN 395-8392
Unless otherwise stated, any opinions expressed here are strictly my own
and do not reflect any official position of Nortel Networks.
------------------------------
Crossposted-To: comp.os.linux.development.apps
From: [EMAIL PROTECTED] (Stephen Harris)
Subject: Re: Zero padding in sprintf() doesn't work for strings - HELP !
Date: Fri, 31 Mar 2000 06:48:41 GMT
Juergen Heinzl ([EMAIL PROTECTED]) wrote:
: In article <8briic$ofu$[EMAIL PROTECTED]>, bill davidsen wrote:
[ Re 0 padding of strings ]
: > Another reason why it should be changed. Both AIX and hp-ux pad with
: >zeros as expected, so it would be at minimum acceptable to do it that
: ... conversions and the same as far as the Unix98 specification
: is concerned, so your installations of AIX and HP-UX are doing it
: wrong and you might see whether there is an appropriate patch.
Solaris 7 does it with zero's as well, although the manpage doesn't
say it should :-)
It sort of makes sense - if you want space padding, then the default syntax
without a zero does that for you.
--
Stephen Harris
[EMAIL PROTECTED] http://www.spuddy.org/
The truth is the truth, and opinion just opinion. But what is what?
My employer pays to ignore my opinions; you get to do it for free.
* Meeeeow ! Call Spud the Cat on > 01708 442043 < for free Usenet access *
------------------------------
From: John Gluck <[EMAIL PROTECTED]>
Subject: Re: Hard disk DMA access, SMP bug?
Date: Fri, 31 Mar 2000 13:19:35 -0500
The Hedge Fox wrote:
>
> We tried some Maxtor 40GB UDMA66 5400rpm and IBM 34GB UDMA66 7200rpm
> drives on some Dell 410, 420's with dual P-II and P-III CPUs using
> the 2.2.14 kernel compiled for SMP. The distribution was Mandrake 7.0.
>
> Using hdparm to set DMA access resulted in occasional corruption
> of data on the disk - bad enough to require a mkfs. Switching to
> PIO access fixed the problem. Setting unmask_irq didn't seem to
> hurt at all. The corruption occurred with ext2, ext3 and reiserfs.
>
> Running the same hard disks with UDMA on a uniprocressor machine w/o SMP
> but the same kernel and distribution was OK, none of the problems
> on the dual CPU machines.
>
> Has anyone else encountered this problem? Why would DMA access be
> a problem with an SMP kernel?
> --
> C. Chan < [EMAIL PROTECTED] >
> PGP Public Key: finger [EMAIL PROTECTED]
I seem to remember reading somewhere that DMA doesn't work on all
motherboards.
If I recall it's when you do the kernel config theres's a question about
enableing DMA by default. The help for it talks about the possibility of
errors on some hardware. I don't know the details of which hardware.
In my case I have a Tyan S1836DLUAN with dual PIIIs and several hard
disks 2 of which are IDE. I use a 2.2.13 kernel compiled for SMP and
haven't had a problem.
--
John Gluck (Passport Kernel Design Group)
(613) 765-8392 ESN 395-8392
Unless otherwise stated, any opinions expressed here are strictly my own
and do not reflect any official position of Nortel Networks.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Precision of Linux's libm???
Reply-To: [EMAIL PROTECTED]
Date: Fri, 31 Mar 2000 19:00:21 GMT
[EMAIL PROTECTED] (bill davidsen) writes:
> I will just note here, gcc supports "long double" to allow use of 80
>bit results stored in variables. This is not (a) portable nor (b) a
>substitute for good numerical analysis, but it does allow things which
>just would not produce any significant digits otherwise.
And in case you *don't* use this, you really want to switch the FPU
itself to do 64/53 bit rounding. Eventually, your data will be read
from the FPU, and stored in a "double" --- and if that involves a
80 -> 64 conversion, that data has been rounded twice, which is a big
nono.
I actually ran into this a few years back, when I got results of the
form (decimal numbers used for explanation purpose here)
x=0.426374665000000000001
which was first rounded *inside* the FPU, to something like
x=0.426374665000
and then, upon being transferred from the FPU to memory, rounded again,
to give the incorrect
x=0.42637466
(because of round-to-nearest, if in middle, round-to-even).
Depending on what environment you are using, you'll have to use either
#include <fpu_control.h>
inline void __setfpucw(u32 cw) { _FPU_SETCW(cw); }
main() {
[...]
__setfpucw(0x127f);
[...]
}
for glibc 2.1, or just
main() {
[...]
__setfpucw(0x127f);
[...]
}
for glibc 2.0/libc4/libc5. If you don't like compiler warnings or are doing
C++, you'll have to provide a prototype for that function.
Regards,
Bernie
--
I never vote. It only encourages them
Elderly American lady quoted by comedian Jack Parr
------------------------------
From: John Peterson <[EMAIL PROTECTED]>
Crossposted-To:
news.announce.newgroups,news.groups,comp.os.linux.portable,comp.arch.embedded,comp.dsp,comp.os.linux.announce
Subject: RFD: comp.os.linux.embedded
Date: Thu, 30 Mar 2000 22:43:33 GMT
REQUEST FOR DISCUSSION (RFD)
unmoderated group comp.os.linux.embedded
This is a formal Request For Discussion (RFD) for the creation of a
world-wide unmoderated Usenet newsgroup comp.os.linux.embedded. This
is not a Call for Votes (CFV); you cannot vote at this time.
Procedural details are below.
Newsgroup line:
comp.os.linux.embedded Linux operating system on embedded hardware.
RATIONALE: comp.os.linux.embedded
It is becoming apparent that the Linux operating system has a
very bright future in the area of embedded applications; internet
appliances, wireless internet access, personal digital assistants,
television set top boxes, medical instruments, dedicated control
systems, etc. The potential for the growth of Linux in this area is
highlighted by the fact that roughly 95% of all newly manufactured
microcomputer chips are used for embedded applications.
Industry has already embraced Linux for use in embedded applications
for several reasons. The cost of licensing a commercial operating
system and the power of the open source development model are some
of the more prominent ones. The TiVo personal video recorder,
and the Empeg MP3 car player are two examples of consumer products
that utilize embedded Linux. Samsung has recently announced plans to
market the world's first Linux based PDA, named Yopy. Sony already
uses Linux based systems for developing applications for it's
Playstation2 game machine. The industry has further demonstrated
it's commitment to Linux by the recent announcement of the formation
of the Embedded Linux Consortium (ELC). It will consist of roughly
50 member companies including IBM, Lineo, Motorola and Red Hat.
Linux development has historically been oriented toward desktop
and server applications and the current comp.os.linux.* hierarchy
largely reflects this heritage. The unique nature of the technical
issues of using Linux for embedded applications, and the potential
for enormous growth are the two main reasons for the proposal of
this new Usenet newsgroup.
There will be some overlap of the charter of the proposed group
will that of the existing comp.os.linux.portable newsgroup. This
is unavoidable since some embedded devices are designed with the
intent to provide portable computing resources of a rather general
nature (PDAs for example). However, the universe of embedded devices
that would not be classified as a portable computer is very large
(e.g. TV set top boxes, medical instruments). It is the contention of
the proponent that the proposed group is sufficiently disjoint from
the existing comp.os.linux.portable newsgroup that the efficiency
and viability of both groups would not be negatively impacted.
Topics related to the use of Linux on embedded processors are
already frequently discussed in several existing Usenet newsgroups
and mailing lists. Statistics for such postings during the period
from Jan 1, 2000 to Jan 31, 2000 are shown in the table below. The
Usenet statistics were gathered using "Power" keyword searches
from the Deja search engine at http://www.deja.com/home_ps.shtml
Newsgroup / Mailing List Posts Search Keyword
======================== ===== ====== =======
comp.arch.embedded 151 "Linux"
comp.dsp 41 "Linux"
comp.realtime 24 "Linux"
comp.os.linux.development.system 17 "embedded"
comp.os.linux.hardware 8 "embedded"
uclinux mailing list 135 N.A.
---
Total Postings 376
Average / Day 12 (376/31)
CHARTER: comp.os.linux.embedded
The proposed newsgroup is intended to be a public forum for the
discussion of the development and use of the Linux operating system
on embedded hardware platforms. Topics considered appropriate for
posting to the group might include (but are not limited to);
o Software Related Topics
+ Embedded Linux distributions (e.g. Lineo Embedix, Mobile Linux)
+ Software APIs for embedded Linux development (e.g. Cygnus EL/IX)
+ Development of user applications for embedded Linux
+ Integrated Development Environments for embedded Linux
o Hardware Related Topics
+ Linux based emulators and debuggers for embedded hardware
+ Existing Linux support for specific hardware
+ Development of device drivers for embedded Linux
Topics that might appear welcome on the surface, but in fact are not
include; general questions about embedded hardware with no reference
to Linux, questions about embedded or real time programming that
are not specific to Linux, such as "What is multithreading?", or
"What is a deadlock?", etc.
One time postings of commercial product announcements or postings of
a commercial nature that are replies to another posted inquiry will
be considered appropriate. However, as in most other Usenet groups,
repeated or in-discriminant posting of commercial advertisements will
be prohibited. Postings using MIME, HTML formats are discouraged
since many Usenet readers do not use web browsers. The posting of
source code and binaries for the purpose of distribution shall be
prohibited. However, a small snippet of source code or a small patch
would be considered acceptable.
END CHARTER.
PROCEDURE:
This is a request for discussion, not a call for votes. In this phase
of the process, any potential problems with the proposed newsgroups
should be raised and resolved. The discussion period will continue
for a minimum of 21 days (starting from when the first RFD for this
proposal is posted to news.announce.newgroups), after which a Call For
Votes (CFV) may be posted by a neutral vote taker if the discussion
warrants it. Please do not attempt to vote until this happens.
All discussion of this proposal should be posted to news.groups.
This RFD attempts to comply fully with the Usenet newsgroup creation
guidelines outlined in "How to Create a New Usenet Newsgroup" and "How
to Format and Submit a New Group Proposal". Please refer to these
documents (available in news.announce.newgroups) if you have any
questions about the process.
DISTRIBUTION:
This RFD has been posted to the following newsgroups:
news.announce.newgroups
news.groups
comp.os.linux.announce
comp.os.linux.development.system
comp.os.linux.portable
comp.arch.embedded
comp.dsp
This RFD has been posted to the following mailing lists;
[EMAIL PROTECTED] (discussion of Linux on systems without a MMU)
To subscribe, send a mail message to <[EMAIL PROTECTED]>
with 'subscribe uclinux' in the body of the mail message
Proponent: John Peterson <[EMAIL PROTECTED]>
------------------------------
From: Badrinath Venkatachari <[EMAIL PROTECTED]>
Subject: interruptible_sleep_on() problem...
Date: Fri, 31 Mar 2000 15:05:01 -0800
Hi,
I am trying to capture all read requests in the kernel, queue them up
and process them every some seconds out of sync with the requesting
process's context...for this my code is :
The processing of Qing requests is started when an LKM is a loaded.
This LKM sets a flag and starts a timer for a function to deQ requests
periodically. Since a requests are handled out of the context of the
process requesting the data blocks, I have the process sleeping on
wait_queue till the buffer_head has been serviced by the timer driven
function. this wait_queue is a part of the node (struct req) that gets
Qued since I need to know which process to wakeup....I am trying to
maintain a 1-1 correspondence between struct req and the process for
which it is created...so that wake_up would do so the only process that
should be woken up.
But there is something wrong in my assumptions and code that make the
system just report all sorts of errors....just too many to capture and
put here...but the bottomline being that is this mechanism does not
work....I am inclined to believe that there is may be something else
that I have to do apart from interruptible_sleep_on ??? I have pasted
the necessary code....
Please help....any ideas or pointers would be greatly appreciated....
thanks a lot in advance
regards
badri
---- Code ----
struct semaphore semQ = MUTEX;
struct req /* this is the node added to the Q to hold information about
a read
request */
{
int major, rw;
struct buffer_head *bh;
struct wait_queue *wq; /* the requesting process's context is stored
here and used later by the timer function to wake_up the appropriate
process after issuing make_request and getting the buffer_head filled*/
struct req *next;
};
/* this function replaces make_request() in ll_rw_block() for only read
operations*/
Q_request(int major, int rw, struct buffer_head *bh)
{
if (! flag)
make_request(major, rw, bh);
else
{
struct req *rq;
rq = (struct req*) kmalloc(sizeof(struct req), GFP_ATOMIC);
rq->major = major; rq->rw = rw; rq->bh = bh;
rq->wq= NULL; rq->next = NULL;
/* Q the request */
down(&semQ);
addRequestToQ(rq); /* adds this request to a Q by encapsulating it
in another
struct req*/
up(&semQ);
interruptible_sleep_on(&rq->wq);
}
}
/* a timer driven function to deQ requests and process them */
void serviceRequests()
{
struct req *rq;
/* code for creating a timer to call itself once again after
sometime*/
/* service requests out of the requesting processes context */
for (i = 0; i < 5; i ++)
{
down(&semQ);
deQrequest(rq);
up(&semQ);
make_request(rq->major, rq->rw, rq->bh);
wake_up_interruptible(&rq->wq); /* I am hoping the rq->wq will
still have the context of the process that created this rq in the first
place
}
}
------------------------------
From: [EMAIL PROTECTED] (DHodson)
Subject: Increasing # of semaphores in semaphore set?
Date: 31 Mar 2000 21:43:29 GMT
Does anybody know if it is easy to increase the number of IPC semaphores that
can be contained within a set?
I think the limit right now is 250 semaphore per semid. Do I have to recompile
the kernel to up this number?
Thanks for any help!
Doug
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Precision of Linux's libm???
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: Fri, 31 Mar 2000 22:52:45 GMT
[EMAIL PROTECTED] writes:
> [EMAIL PROTECTED] (bill davidsen) writes:
>
> > I will just note here, gcc supports "long double" to allow use of 80
> >bit results stored in variables. This is not (a) portable nor (b) a
> >substitute for good numerical analysis, but it does allow things which
> >just would not produce any significant digits otherwise.
>
> And in case you *don't* use this, you really want to switch the FPU
> itself to do 64/53 bit rounding. Eventually, your data will be read
> from the FPU, and stored in a "double" --- and if that involves a
> 80 -> 64 conversion, that data has been rounded twice, which is a big
> nono.
good observation
it would be nice if linux simply defaulted to the 64-bit float
format on ia32 and avoided the 80-bit bastard altogether.
correct me if i'm wrong but
1) internally, the ia32 is a bit faster with smaller float setting.
2) 10 byte quantities do not align on power of two boundaries very
well. using 80 bits, choose your poison:
- double rounding
- aligned with lots of wasted space
- packed with poor performance
3) no one else uses 80-bit floats. double-precision is nearly
synomous with 64 bits these days.
4) most code uses plain double and expects double to be 64 bits.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: [EMAIL PROTECTED] (Victor Wagner)
Crossposted-To:
ahn.tech.linux,alt.os.linux.dial-up,comp.os.linux.development.apps,comp.os.linux.misc,cz.comp.linux
Subject: Re: Compile IMG
Date: 31 Mar 2000 22:24:40 +0400
In comp.os.linux.misc onno janony <[EMAIL PROTECTED]> wrote:
: How do I compile IMG??? (Like the bootimg's on the RedHat CD (initrd.img)
: I want to compile a boot floppy into an IMG so I can use a dos menu to run
: loadlin vmlinuz initrd=loadme.img
Img is not to be compilied - it is real image of file system to be
loaded at startup.
You should create a file system (for instance, on floppy), populate it
with neccessary files (i.e. kernel modules) and then use dd to copy it
to file.
Alternatively, you may create empty file using
dd if=/dev/zero of=myimg.img count=2880 bs=512
(to be same as 1.44 flopy)
then run mkfs on it (minix filesystem is preferrable becouse it have
less overhead than ext2), then mount it with -o loop option
and populate with files.
You'll need loopback device support in you kernel.
Refer to /usr/src/linux/Documentation/initrd.txt for more inforamtion.
: If you know the solution, please mail it to me @
: [EMAIL PROTECTED] Thnk you!
--
������� �����? ����� ������.
--- �.�. ���
------------------------------
From: Harlan Grove <[EMAIL PROTECTED]>
Subject: Re: Precision of Linux's libm???
Crossposted-To: comp.os.linux.misc,comp.os.linux.development.apps
Date: Fri, 31 Mar 2000 15:54:19 -0800
In article <[EMAIL PROTECTED]>, Johan Kullstam
<[EMAIL PROTECTED]> wrote:
<snip>
>correct me if i'm wrong but
>1) internally, the ia32 is a bit faster with smaller
> float setting.
Shouldn't be in terms of calculation, but may be in terms
of moving data between the FPU and memory. My old book on
Intel 8087 assembler says all internal operations are 80
bit, so even if data is stored as 32-bit floats, the FPU
will convert them to 80 bits before using them.
>2) 10 byte quantities do not align on power of two
> boundaries very well. using 80 bits, choose your poison:
> - double rounding
> - aligned with lots of wasted space
> - packed with poor performance
But if the bulk of or the entire data for a particular
calculation were stored in the CPU cache, would there be a
significant performance problem with packed data? The CPU
would load/store several KB of memory at a time, so the
only plausible drag would come from cache-FPU load/store
operations. [Granted not all Intel-based linux machines
have CPU memory caches.]
* Sent from AltaVista http://www.altavista.com Where you can also find related Web
Pages, Images, Audios, Videos, News, and Shopping. Smart is Beautiful
------------------------------
** 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
******************************
