Linux-Development-Sys Digest #666, Volume #6 Fri, 30 Apr 99 22:14:13 EDT
Contents:
Re: Audio filesystem ? (Oleg Krivosheev)
Re: Is Linux Y2K compliant? ("T.E.Dickey")
Re: physical Memory (Robert Kaiser)
[ANN] CodeWarrior for Red Hat Linux, GNU ed. Shipping (MW Ron)
Re: Linux for CompactPCI BUS? (Bob Hauck)
Re: Is Linux Y2K compliant? (Don Baccus)
Re: glibc-2.1 and incompatible apps (Juergen Heinzl)
Re: Linux system ID, is there such a thing? ("G. Sumner Hayes")
Re: stdio SMBd - name your price (Jeremy Allison)
Re: Driver access to File System ("new.ccu.edu.tw")
/dev/hda1 has reached maximal mount count, check forced ("David Peavey")
Re: Possible?: glibc-2 system and (old?) Motif libraries (Juergen Heinzl)
Re: /dev/hda1 has reached maximal mount count, check forced (ellis)
Re: mkinitrd problems with 2.2.6 (Peter Samuelson)
Re: Threads >> PThreads or LinuxThreads?? (Philipp Thomas)
Re: Best way-Kernel notify User (DMA) (Robert Kaiser)
Re: Best way-Kernel notify User (DMA) (Peter Samuelson)
----------------------------------------------------------------------------
From: Oleg Krivosheev <[EMAIL PROTECTED]>
Subject: Re: Audio filesystem ?
Date: 30 Apr 1999 12:36:50 -0500
[EMAIL PROTECTED] (Thomas Huber) writes:
> Hello,
>
> Is there an 'audio filesystem' for Linux ?
http://fly.cc.fer.hr/~ptolomei/audiofs/
> With
> audio filesystem I mean to be able to mount an
> audio-CD and then see the audiotracks on the CD
> in .wav or whatever format.
>
> > mount /dev/cdrom/ /audio
> > cd /audio
> > ls
> track1.wav
> track2.wav
> track3.wav
> >
>
> This would be way (too?) cooool
>
>
> Thomas
OK
------------------------------
From: "T.E.Dickey" <[EMAIL PROTECTED]>
Subject: Re: Is Linux Y2K compliant?
Date: Fri, 30 Apr 1999 19:31:26 GMT
Don Baccus <[EMAIL PROTECTED]> wrote:
> Heck, I spent my early days trying to cram lots of functionality
> into little PDP-8 boxes. The boxes were relatively expensive,
> my time relatively cheap. Now, it's far cheaper just to buy
> more RAM in most cases. The constraints have changed.
yes (wasn't that a 4k 12-bit word address space on PDP-8, iirc)
> And, of course, hindsight makes a genius of every gadfly...
most of the people complaining were (a) not programming during that
time (hadn't learned to read yet), or (b) weren't as loud at complaining
as they claim.
--
Thomas E. Dickey
[EMAIL PROTECTED]
http://www.clark.net/pub/dickey
------------------------------
From: [EMAIL PROTECTED] (Robert Kaiser)
Subject: Re: physical Memory
Date: 30 Apr 1999 20:06:50 GMT
In article <[EMAIL PROTECTED]>,
Wolfram Gloger <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Robert Kaiser) writes:
>
> So you're saying that e.g. the bttv driver could be made faster just
> by rewriting it to perform DMA into user space ?
>
No, I don't know enough about the bttv driver in particular to say
something like that, but, judging from the source code I quoted, the
bttv driver's author himself doesn't seem to be happy about kludges
he has to use.
I have personally written a driver for a frame grabber that can
transfer 50MB/second into user space Memory AND the CPU has plenty of
time left to compute the images while the transfer is going on. Try
that with an unpatched Linux kernel!
[And before that misunderstanding comes up again: no, the frame GRABBER
I'm talking about does not have a frame BUFFER of it's own. It transfers
video data directly into the host's memory via PCI busmaster DMA. Thus
it's more like a fast A/D converter].
> Linus preached:
>
>> > Basically you should never EVER even consider writing to user space from
>> > interrupts. EVER!
>> >
>> > Basically, you should always use a kernel-space buffer. Just accept that
>> > as a fundamental notion, and your life suddenly turns a lot easier.
>> >
>>
>> As a matter of fact _my_ life was a lot harder before I developed the
>> patch to circumvent this silly restriction....
>>
>> > Now, I know about zero-copy. I'm not a big believer in it, but I certainly
>> > know about it. And having a kernel buffer does not imply that you can't do
>> > zero-copy. It just means that you can' tdo the initial copy to user space.
>> >
>>
>> It also means that you have to do something in a driver that logically
>> belongs into the application. The result being that the driver has to
>> do a lot of error-prone bookkeeping (keeping track of which process
>> owns which DMA buffer -- what if the process suddenly gets killed ?) that
>> would otherwise be unnecessary.
>
> I don't see the point, sorry. With the DMA buffer in the kernel,
> there is only _one_ buffer to keep track of. Whether a process
> mapping that buffer dies is totally irrelevant for the driver, because
> the driver owns the memory.
... and that's exactly what's wrong with this approach here (read on).
[snip]
>> Sure, but this way, a driver will always be forced to use a non-standard,
>> cryptic protocol (i.e. mmap(), ioctl()) to implement DMA.
>
> What ?? This is Unix, mmap() is the perfectly standard, proven method
> to do these things. (Of course there are other methods that may work
> as well, no question.)
>
>> The application has to be written
>> specifically to match this interface. Basically, the driver is divided
>> into a kernel part and a user-space part with a kludgy interface in
>> between.
>
> What user space part ? You mean the integer constants passed via
> ioctl() ?
They are not constants, otherwise it would be pointless to pass them
via ioctl().
Look, I suspect we have fundamentally different ideas of the hardware
we are talking about. I am _not_ talking about a device with local
RAM (e.g. a frame buffer). Of course, a frame buffer's memory belongs
to the device and so it is only logical that the driver should own
that memory. mmap() is a perfectly sound approach in this situation.
But, OTOH, consider something like a tape device: Nothing is more
natural than doing a read() call to such a device's driver. That
read() call moves data from the device into a user space buffer.
If the device supports scatter/gather DMA (which many do), it would
physically be able to store it's data to the user buffer right away,
without the CPU getting involved in the process. But, currently,
if I want to write such a driver for Linux, I have no choice but to:
- waste memory to allocate a kernel space buffer,
- DMA to that buffer,
- waste CPU time to copy the data from one place in memory
(the kernel buffer) to another place in memory (the user
process's buffer).
Why not DMA directly to the place where I want the data to end up ?
This waste of both memory and CPU is not a problem as long as
you are dealing with slow data rates and small amounts of data,
but for that frame buffer I mentioned, the CPU would have to
move data at a rate of 50 Megs per second in order to keep up
with the device. Even a fast CPU wouldn't have much computation
power left with that kind of load.
Of course, I _could_ do this with mmap(). Instead of a simple read(),
I would have to:
1) tell the driver the amount of data I want to read (presumably
with a nonstandard ioctl()) so it can allocate an appropriately
sized kernel buffer for me.
2) mmap() that buffer into user space (after the driver has given
me the information I need for that (physical address) -- another
nonstandard ioctl() (well I could combine it with the first
ioctl(), to be fair))
3) when I'm finished processing the data, tell the driver to
de-allocate the buffer -- yet another nonstandard ioctl().
* What if my process gets killed before it has a chance do that
last deallocation ioctl() ? (well, the driver's close() function
could deal with that, but that means the driver has to keep track
of the buffer(s) it has allocated)
* What if multiple processes use the same device ? The driver
has to allocate multiple buffers simultaneously (how many ?
where is the limit) and it must keep track of which buffer
belongs to which process.
Now, _that's_ what I call a kludgy interface!
The reason for this mess is that, unlike in the frame buffer case,
the buffer here logically belongs to the user program and Linux
forces me to have the driver own it because otherwise I can't
DMA to it. Thus, I have to communicate bookkeeping info between
user process and driver. The application has to be written specifically
for the particular driver's crude API where it otherwise could
have used a simple, standard read() system call. Both the driver
and the application get unnecessarily complicated and error prone.
>> Look at it this way: the plain simple read() call transfers data
>> from a device into a user-space buffer. Nobody seems to have a problem
>> with that. Why on earth does everybody seem to have such a hard time
>> accepting that there is absolutely no need to change this if the
>> hardware can do the transfer with DMA ?
>
> Well, what if I want to share the DMA buffer between different
> processes ? This is trivially possible with mmap() but impossible
> with read().
Why would that be impossible ? I would just create a shared memory
segment and read() data into that segment.
Cheers
Rob
================================================================
Robert Kaiser email: rkaiser AT sysgo DOT de
SYSGO RTS GmbH
Mainz / Germany
------------------------------
From: [EMAIL PROTECTED] (MW Ron)
Crossposted-To: comp.os.linux.development.apps,comp.unix.programmer
Subject: [ANN] CodeWarrior for Red Hat Linux, GNU ed. Shipping
Date: Fri, 30 Apr 1999 12:24:41 -0400
My apologies if this is posted more than once
Linux Warriors
CodeWarrior for Red Hat Linux, GNU Edition is now Shipping.
CodeWarrior for Red Hat Linux, GNU Edition is available immediately
through Ingram Micro and all CompUSA and Micro Center outlets.�CodeWarrior
for Red Hat Linux, GNU edition, which includes the award-winning
CodeWarrior IDE using a GNU compiler and debugger.
For further information visit Metrowerks CodeWarrior's web site
http://www.metrowerks.com
CodeWarrior for Red Hat Linux, Professional Edition, will become available
during the fourth calendar quarter of 1999 and will include integrated
compilers and debuggers from Metrowerks for C, C++, and Java.
For a full list of distributors and resellers visit
www.metrowerks.com/buy.� For pricing and availability outside the USA and
Canada, please e-mail [EMAIL PROTECTED]
--
METROWERKS Ron Liechty
"Software at Work" [EMAIL PROTECTED]
------------------------------
From: Bob Hauck <b o b h @ w a s a t c h . c o m>
Subject: Re: Linux for CompactPCI BUS?
Date: 30 Apr 1999 12:13:29 -0600
[EMAIL PROTECTED] (Peter Samuelson) writes:
> [(cosc1) 95h02740 <[EMAIL PROTECTED]>]
> > That is good. It would be fun to build a telco Central Office
> > or Mobile Switch on Linux. But hot swapable is definitely a
> > desired feature, and RealTime Linux is also helpful.
>
> How hard would it be to add support for rescanning the PCI bus? That's
> basically what is needed, right?
That plus detection of hot-plug events and powering the slots on/off.
Of course this requires that you detect whether the hardware has support
for those features too. It would also be nice if some kind of partial
recan could be done, otherwise you shut down all the devices while you
rescan (which would be a bummer in a Central Office). This gets a bit
messy because of the requirement that bridge chips manage contiguous
resources.
I haven't looked at the 2.2 kernel, but didn't 2.0 get PCI information
from the BIOS?
--
12:00:00 up 66 days, 1:21, 1 user, load average: 0.01, 0.01, 0.00
------------------------------
Subject: Re: Is Linux Y2K compliant?
From: [EMAIL PROTECTED] (Don Baccus)
Date: 30 Apr 1999 11:15:27 PST
In article <[EMAIL PROTECTED]>,
Don Baccus <[EMAIL PROTECTED]> wrote:
>The
>fact that a cost argument, and unanticipated lifetimes for
>(parts of, at least) some commercial applications
>does
^ error, missing "not" :(
>absolve developers of more recent stuff, of course. Which,
>again, I pointed out in my first post.
--
- Don Baccus, Portland OR <[EMAIL PROTECTED]>
Nature photos, on-line guides, at http://donb.photo.net
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: glibc-2.1 and incompatible apps
Date: Fri, 30 Apr 1999 23:07:24 GMT
In article <[EMAIL PROTECTED]>, "Stefan Monnier wrote:
>
>How do people work around the problem of applications compiled
>for glibc-2.0 that don't work with glibc-2.1 any more ?
>I guess I can keep a glibc-2.0 around and play around with LD_LIBRARY_PATH,
No.
[...]
>Any recommendation ?
Compile'em yourself or get the 2.1.x version; the only application yet
that causes trouble is Applixware and for that one I've got a workaround,
more or less.
Alternatively use libc5 versions, the memory overhead is not that much.
>PS: I currently only have such problems with rstatd and amandad (both
> of which using UDP, funnily enough).
See above.
Cheers,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Linux system ID, is there such a thing?
Date: Fri, 30 Apr 1999 19:38:19 -0400
"Jonathan A. Buzzard" wrote:
> The *really* funny thing about dongles is watching a dongle work the
> far side of a automatic parallel switch, with several computers using
> the same dongle simultaneously without any problems.
That'll only work if the dongle is reentrant, of course. If it's
stateful, you could have problems.
Hmmm. Visions of non-reentrant dongles designed to work with
multi-threaded programs that marshal dongle access through a single
thread are dancing in my mind. It's amazing how much time is wasted
on intractable problems.
Anyone else seen the advert that shows a stereotypical Greek statue
of nude male sans phallus, with the caption "lost the dongle?" It's
a couple of years old now.
--Sumner
------------------------------
Crossposted-To: comp.protocols.smb,comp.unix.solaris
From: [EMAIL PROTECTED] (Jeremy Allison)
Subject: Re: stdio SMBd - name your price
Date: Fri, 30 Apr 1999 23:14:58 GMT
[EMAIL PROTECTED] (Kyler Laird) writes:
>[I've asked for this before, usually with a few hundred
>The result would, of course, be open to the public.
>(I'll leave licensing to the author.)
Well if it's based on the Samba code the licensing
would be GPL of course.....
Regards,
Jeremy Allison,
Samba Team.
------------------------------
From: "new.ccu.edu.tw" <[EMAIL PROTECTED]>
Subject: Re: Driver access to File System
Date: Sat, 1 May 1999 08:02:59 +0800
>Does anyone know how to read the file system from a kernel driver? I
>have been trying sys_open with no luck.
>
>Kyle
Maybe I can provide a trivial way. Pick the file structure of the file to
be read. And call filp->f_op->read() to read it. It indeed works in pipe,
and I think it should work fine too in normal file.
------------------------------
From: "David Peavey" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: /dev/hda1 has reached maximal mount count, check forced
Date: Fri, 30 Apr 1999 16:59:13 -0700
/dev/hda1 has reached maximal mount count, check forced
I get this message sometimes when I boot up. Can someone tell me what this
means (besides the obvious)? How do fix it? We are doing some system
integration work here and this message occurs occasionally.
Thanks
Dave
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Possible?: glibc-2 system and (old?) Motif libraries
Date: Fri, 30 Apr 1999 23:07:23 GMT
In article <[EMAIL PROTECTED]>, Remco van den Berg wrote:
>When I try to compile motif applications like Nedit I get linker errors
>of undefined references:
>
>libXm.so: undefined reference to '_xstat'
> '_fxstat'
> '_Xsetlocale'
>
>These problems are caused by the fact that I upgraded my system to the new
>glibc-2.x
No go.
>Is it possible to solve this problem with a linker trick, or do I have to
>buy a new Motif release?
Yes, either upgrade or use a static nedit binary. Motif 2.0.x, glibc
version, is available for quite some time and I've got it here too. Fine
so far, no problems.
Cheers,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: [EMAIL PROTECTED] (ellis)
Crossposted-To: comp.os.linux.hardware
Subject: Re: /dev/hda1 has reached maximal mount count, check forced
Date: 1 May 1999 01:13:39 GMT
In article <7gdg1b$[EMAIL PROTECTED]>,
David Peavey <[EMAIL PROTECTED]> wrote:
>/dev/hda1 has reached maximal mount count, check forced
>
>I get this message sometimes when I boot up. Can someone tell me what this
>means (besides the obvious)? How do fix it? We are doing some system
>integration work here and this message occurs occasionally.
After a number of mounts an fsck is forced even though no errors have
been detected. You can change the number of mounts before a check
with tune2fs.
--
http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: mkinitrd problems with 2.2.6
Date: 30 Apr 1999 20:08:53 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Brandon Hale <[EMAIL PROTECTED]>]
> When I try to run mkinitrd /boot/initrd-2.2.6.img 2.2.6 I get an
> error that says it connot find a loopback device and if I use -v it
> tells me that /dev/loop0 is not a block device. I am running a
> adaptec 2940 and it does find the aic7xxx.o module.
Are you running a kernel with loopback mount support (either compiled
in or as a module)? You need to be. CONFIG_BLK_DEV_LOOP is in the
"Block Devices" section of the kernel config.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Philipp Thomas)
Subject: Re: Threads >> PThreads or LinuxThreads??
Date: Fri, 30 Apr 1999 23:34:00 GMT
On 27 Apr 1999 13:50:35 +0200, Martin Recktenwald
>> ... and glibc-2.1 is available. I've to know since it is a somewhat
>> patched 2.1.1pre1 system here.
>
>prep.ai.mit.edu:/gnu/glibc/glibc-2.1-README:
>
>"glibc-2.1 has been (temporarily) removed, until some
>political issues are worked out."
http://sourceware.cygnus.com is your friend :))
Philipp Thomas
--
caffeine low .... brain halted
------------------------------
From: [EMAIL PROTECTED] (Robert Kaiser)
Subject: Re: Best way-Kernel notify User (DMA)
Date: 30 Apr 1999 20:28:09 GMT
Herman,
In article <[EMAIL PROTECTED]>,
herman <[EMAIL PROTECTED]> writes:
> I am writing a Bus Master DMA driver to collect streaming data to hard
> disk drive files. The buffer size is 16MBytes with 256KByte pages (64
> pages total) and a data rate around 1MB/sec. I am going to use either
> Matt Welch's BigPhysArea Patch or Allesandro Rubini's Allocator to set
> up the large DMA area. The transfers are whole page (256KByte)
> transfers handled by the bus master hardware. An interrupt occurs when
> a page is filled and ready to dump to disk.
>
> When the interrupt occurs, the driver needs to notify the user to write
> page data to a hard disk file.
>
> I have three potential ways of notifying the user...which way would be
> the best?
>
> 1. The user calls 'read', and the driver blocks with
> 'interuptible_sleep_on' till a page is full. When page is full, the
> read call can return with info about the buffer.
I'd say, of the alternatives you have given, this one is the
best, BUT:
Please, have a look at ftp://ftp.sysgo.de/pub/Linux . The
kernel patch available from that site enables you to let your
driver DMA directly into the user process's buffer. Thus, you
could do a read() and that call would return with the data (not
just info about it) in the buffer. You could even implement
scatter/gather DMA and thus transfer multiple pages with a
single read() call. Plus, you won't have to dedicate 16 Megabytes
of your system's RAM solely for DMA purposes.
Also, check out the thread "physical Memory" in this newsgroup.
Hope this helps
Rob
================================================================
Robert Kaiser email: rkaiser AT sysgo DOT de
SYSGO RTS GmbH
Mainz / Germany
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Best way-Kernel notify User (DMA)
Date: 30 Apr 1999 20:45:01 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[herman <[EMAIL PROTECTED]>]
> I am writing a Bus Master DMA driver to collect streaming data to
> hard disk drive files. The buffer size is 16MBytes with 256KByte
> pages (64 pages total) and a data rate around 1MB/sec. I am going to
> use either Matt Welch's BigPhysArea Patch or Allesandro Rubini's
> Allocator to set up the large DMA area.
Please tell me this hardware to which you are about to dedicate 16M of
memory can at least do scatter/gather. If so there is no need for
bigphysarea....
> 1. The user calls 'read', and the driver blocks with
> 'interuptible_sleep_on' till a page is full. When page is full, the
> read call can return with info about the buffer.
Ewww, that's seriously overloading read(). You want an ioctl. Or --
and, not being a kernel guy, I don't know how possible and/or clean
this would be -- you could (a) let the app mmap() the 64 buffers, (b)
map every buffer such that it will pagefault if the user tries to read
it, (c) trap any such pagefaults and block the callers, (d) when a
given buffer is ready, remap it so the user gets it instead of
pagefaulting, and (e) wake up anyone you put to sleep during (c).
(Actually (b) comes before/during (a).)
> 2. The User program can continuously poll a variable that is changed
> with 'put_user' when a page is ready to write to the disk.
Ick.
> I need confirmmation that the virtual addresses (vremap) of the
> buffer are the same on both the kernel and user side (since the
> buffer is outside of both).
Read Documentation/IO-mapping.txt, which is or at least should be
required reading for anyone coding anthing to do with DMA. Whatever
questions it doesn't answer, ask again.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
** 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
******************************
