Linux-Development-Sys Digest #673, Volume #6 Mon, 3 May 99 15:14:22 EDT
Contents:
Re: Memory based filesystem (Daniel Robert Franklin)
Re: register_filesystem (Peter Samuelson)
Re: physical Memory (Wolfram Gloger)
Re: Mac-emulation on Linux? (Andrew J. Brehm)
Re: [ANN] CodeWarrior for Red Hat Linux, GNU ed. Shipping ([EMAIL PROTECTED])
Net-tools 1.50 and Kernel 2.0.29 - Compiler Error? ("Avi Kivity")
`egcs' or `gcc' (J.H.M. Dassen (Ray))
Memory based filesystem (Wee Teck Ng)
Re: suggestion to scsi-drivers ("Sascha Bohnenkamp")
Re: How can I fix linux buffer cache size? ("Sascha Bohnenkamp")
Re: Linux Real-Time I/O (Alex Maranda)
help with mkisofs... ("Thierry BUCCO")
Re: stdio SMBd - name your price (Kyler Laird)
Powering on terminal (Arthur Rinkel)
Re: Mac-emulation on Linux? (Shimpei Yamashita)
Re: Mac-emulation on Linux? (Rod Smith)
Re: glibc-2.1 and incompatible apps ("David Page")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Daniel Robert Franklin)
Subject: Re: Memory based filesystem
Date: 3 May 99 06:53:05 GMT
[EMAIL PROTECTED] (Wee Teck Ng) writes:
>does linux supports memory based file system (MFS) similar to freebsd?
Is that like a ramdisk? In which case, the answer is yes :-)
- Daniel
--
******************************************************************************
* Daniel Franklin - Postgraduate student in Electrical Engineering
* [EMAIL PROTECTED]
******************************************************************************
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: register_filesystem
Date: 3 May 1999 06:27:56 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[new.ccu.edu.tw <[EMAIL PROTECTED]>]
> When I read code about register_filesystem(), I found that
> there's one field in struct file_system, i.e. fs_flags. After
> looking up, I find there are four constant about it.
GTSL.
> I'm wondering what FS_NO_DACHE, FS_IBASKET means ! Can somebody
> tell me that. Thanks.
If you had grepped even a little bit, you would have noticed that
neither one of those flags does anything at all. (Assuming no
unlabeled magic numbers in the vfs code, of course.) So I think we can
assume both are either unfinished, unbegun or obsolete features.
I assume FS_NO_DCACHE is supposed to indicate that in your filesystem,
dcache entries go stale immediately after use. I have no clue what an
ibasket is/was supposed to be, though it very probably has something to
do with the inode cache.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Wolfram Gloger <[EMAIL PROTECTED]>
Subject: Re: physical Memory
Date: 03 May 1999 12:54:33 +0200
[EMAIL PROTECTED] (Robert Kaiser) writes:
> 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!
Well, I have personally written software using the Matrox meteor frame
grabber that also saturates the PCI bus (with zero-copy, if that's
what you're hinting at). My old, slow CPU wouldn't even be fast
enough to perform a copy at this kind of data rates.
OK, this driver requires the bigphysarea patch, which is about 80
lines of code. This should be in the standard kernel, to that I agree
100% ! (For example, it already _is_ in all Debian kernels.)
> [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].
Same with the matrox meteor and the bt8x8. I have not misunderstood
you.
> > 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().
Huh ? Every ioctl() gets a constant request id, some (of course)
additional parameters, like with every interface. What is bothering
you about 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.
... and in many other situations :-)
> But, OTOH, consider something like a tape device: Nothing is more
> natural than doing a read() call to such a device's driver.
But nothing is stopping you from doing an mmap() either.
> 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,
No, this is the exact same memory that you want to have in userspace.
So it's definitely not wasted.
> - DMA to that buffer,
Yes. Like in the case for DMAing into userspace.
> - 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).
No ! mmap() does this transparently, without copying.
> Why not DMA directly to the place where I want the data to end up ?
Yes, this is exactly what's happening with the mmap() approach.
> 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.
True. But as Linus said, zero-copy is possible even without DMA to
userspace.
> 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.
Same as with read(). Your point is that read() provides a `standard'
version of an ioctl() call with one pointer and one size_t argument ?
Fair enough. But you won't tell me that that is sufficient for things
like a framegrabber, right ? How do I specify that I want continuous
capture into a ring buffer, for example ?
> 2) mmap() that buffer into user space (after the driver has given
> me the information I need for that (physical address)
No, the physical address is of no interest whatsoever to the
application. Processes only deal with virtual addresses. The
application can map the DMA buffer at any address it sees fit.
> 3) when I'm finished processing the data, tell the driver to
> de-allocate the buffer -- yet another nonstandard ioctl().
No, that is just a standard munmap() call.
> * 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)
Yes, of course it has to keep track, because it has allocated the
buffers. (I'm repeating myself.) Actually the driver's munmap()
function (which is implicitly invoked at process exit) deals with it.
> * 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.
No, for the framegrabber and even for the tape, there clearly needs to
be only one buffer per device.
> Now, _that's_ what I call a kludgy interface!
Your choice. All vendors of Unix systems seem to think it's clean
enough.
> > 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.
Aha ! Have you looked at what attaching to a shared memory segment
involves ? Right, exactly the same interface, and a closely related
implementation, as mmap(). But anyway, what if two processes invoke
read() at the same time ? Who gets the frame ?
Don't get me wrong, I actually like your kernel patch! For certain
devices, something like that will probably be very nice to have in the
kernel. But it is not _necessary_ to obtain zero-copy performance
with DMA devices.
Regards,
Wolfram.
------------------------------
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.misc,comp.os.linux.powerpc
Subject: Re: Mac-emulation on Linux?
From: [EMAIL PROTECTED] (Andrew J. Brehm)
Date: Mon, 3 May 1999 12:56:04 +0200
FM <[EMAIL PROTECTED]> wrote:
> 1. Just buy a X86 machine and install Linux on it (if not
> preinstalled). Get some Mac-emulation software if necessary.
Whatever you do, you won't be able to emulate a PowerPC and thus can
only run old MacOS software. I presume the software you were refering to
(college stuff) is rather new.
> 2. Buy a Macintosh and dual boot with Linux/MacOS
>
> Well I think this is a nice compromise but I'm not sure how
> well Linux runs on Macintosh.
Quite good.
> I'm fairly sure that it will
> be an improvement over Windows/MacOS, but I'm not even sure
> if most Linux softwares are available for this setup (or if
> it's generally source-level compatible).
It is source level compatible. And most Linux software is available as
source codes. However, some Linux software is only available as Intel
(Star Office).
> I think my doubts stem mostly from my lack of knowledge
> about the Macintosh systems, which I've used before but
> never administered. Are these the only options I have
> considering that I want to use Linux and remain compatible
> with Mac at the same time? Any additional information
> would be apprecited. Thanks in advance.
Your only option would be to use a Mac.
--
LinuxPPC User
Fan of Woody Allen
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,comp.unix.programmer
Subject: Re: [ANN] CodeWarrior for Red Hat Linux, GNU ed. Shipping
Date: 02 May 1999 20:03:10 -0700
[EMAIL PROTECTED] (MW Ron) writes:
[snip]
> CodeWarrior for Red Hat Linux, GNU Edition is now Shipping.
[snip]
GNU Edition? does that mean it's Free Software? wow!
andru
------------------------------
From: "Avi Kivity" <[EMAIL PROTECTED]>
Subject: Net-tools 1.50 and Kernel 2.0.29 - Compiler Error?
Date: Mon, 3 May 1999 15:07:20 +0200
Net-tools 1.50 will not compile with my kernel, complaining that
linux/pkt_sched.h is missing (file lib/utils.c, line 29). Is this a problem
with configuration, or am I missing a file, or is net-tools broken?
------------------------------
From: [EMAIL PROTECTED] (J.H.M. Dassen (Ray))
Crossposted-To: comp.os.linux.development.apps,comp.unix.programmer
Subject: `egcs' or `gcc'
Date: 3 May 1999 11:11:56 GMT
Peter Samuelson <[EMAIL PROTECTED]> wrote:
>[G. Sumner Hayes <[EMAIL PROTECTED]>]
>> No, that means that it doesn't include a CodeWarrior compiler but is
>> just an IDE for use with egcs/gcc.
> ^^^^^^^^
>Hmmm, I wonder, can we start just saying `gcc' again now that rms et al
>have re-blessed egcs? Or do we have to wait until they release something
>that calls itself gcc again?
I think the latter prevents miscommunication. Judging from the number of
gnu.{gcc,g++}.{bugs,help} postings about gcc 2.8.1 bugs that have already
been fixed in EGCS, many gcc users outside the free unices, in particular on
Solaris, are currently quite unaware of EGCS and the advantages it has over
gcc 2.8.1 and older.
Ray
--
Tevens ben ik van mening dat Nederland overdekt dient te worden.
------------------------------
From: [EMAIL PROTECTED] (Wee Teck Ng)
Subject: Memory based filesystem
Date: 3 May 1999 05:04:28 GMT
does linux supports memory based file system (MFS) similar to freebsd?
thanks
wee teck
------------------------------
From: "Sascha Bohnenkamp" <[EMAIL PROTECTED]>
Subject: Re: suggestion to scsi-drivers
Date: Fri, 30 Apr 1999 15:56:57 +0200
>In article <7g45rp$hbf$[EMAIL PROTECTED]>,
>Sascha Bohnenkamp wrote:
>>Hello,
>>
>>I am a (little) bit disapointed with the scsi-drivers ... yes I know they
>>are fast etc. thats ok, but the naming of the drives is a bit dosish ..
>>
>>example:
>> I have a hard drive scsi-id 0 is the boot-drive and gets /dev/sda
>> I have a cd-rom scsi-id 3 is it and gets /dev/sdb
>
>No, /dev/sdb is the second disk and /dev/sr0 is the first SCSI CDROM, see
>the devices.txt in the Documentation directory.
ok, than i have a hd with scsi-id 0, and one with scsi-id 2 they
get /dev/sda and /dev/sdb now I put a new drive with scsi-id 1 into the
system
and it get dosish mixed ...
------------------------------
From: "Sascha Bohnenkamp" <[EMAIL PROTECTED]>
Subject: Re: How can I fix linux buffer cache size?
Date: Fri, 30 Apr 1999 15:54:21 +0200
>I know linux buffer cache size is dynamic.
>Is there any method to fix buffer cahe size?
why?
------------------------------
From: Alex Maranda <[EMAIL PROTECTED]>
Subject: Re: Linux Real-Time I/O
Date: Mon, 03 May 1999 14:26:56 +0100
Jim & Lisa Meils wrote:
>
> I am a newbie to Linux, and have a somewhat simple question. I have
> written an increadibly simple I/O program for DOS using QBASIC, and
> would like to write a similar program for Linux and possibly use the
> timing and multitasking capabilities to dim lights with it. Currently I
> use the
> parallel port for the output and control up to 8 light circuits. What
> is the best route to take with Linux? Can Linux control in real-time
> i.e. run a routine EXACTLY 120 times/sec ?
8.3 ms...not with the standard kernel; check out RT-Linux (Real Time
Linux) at http://luz.cs.nmt.edu/~rtlinux/
Cheers,
--
Alex Maranda mailto: amaranda at spider dot com
Spider Software Ltd. Tel: +44 (0)131 4757036
Edinburgh, UK http://members.xoom.com/Alex_Maranda
STREAMS based communications protocols for embedded systems
------------------------------
From: "Thierry BUCCO" <[EMAIL PROTECTED]>
Subject: help with mkisofs...
Date: Mon, 03 May 1999 09:44:05 +0200
Hi,
I use mkisofs, and i want to make a new session which contains a file
"directory.dbf", but for each session i want to replace the old
directory.dbf by the new one. And that only the newer is visible...
Is there a way to do that ?
Thanks for your help.
------------------------------
From: [EMAIL PROTECTED] (Kyler Laird)
Crossposted-To: comp.protocols.smb,comp.unix.solaris
Subject: Re: stdio SMBd - name your price
Date: 3 May 1999 14:02:13 GMT
[EMAIL PROTECTED] (Jeremy Allison) writes:
>>Andi Kleen <[EMAIL PROTECTED]> writes:
>>>What the GPL doesn't require though is to distribute
>>>the code. So e.g. if the original poster pays someone to do
>>The hostile reaction I've gotten makes me
>>wonder if it's worthwhile, though.
>I wasn't trying to be hostile (I'm sorry if you perceived
>it as such).
Oh, no. I didn't take your statements that
way. Sorry I wasn't more specific.
>I was only trying to point out that your
>original statement about licensing was incorrect (but only
>if, as someone else pointed out, if you planned to re-distribute
>your changed version).
Yeah, I hadn't thought of it much (that's why
I said I'd leave it to the author). It was
interesting to me, though. After I did
consider it, I started thinking of the
extremes.
>I'm always very careful to try and explain exactly what people
>are getting into if they want to commission changes to Samba,
>just so there are no misunderstandings.
Better than being reactive.
>I'm personally really glad you are thinking of funding someone
>to do these things, it's how the Open Source processes is supposed
>to work.
Unfortunately I'm seeing where some of the
Open Source (or more general) detractors get
their "no one is responsible" complaints. I
have asked for this several times with offers
of money, but I've had no takers. I feel a
bit stranded.
Of course, I realize that I'm in a *much*
better position than if I wanted mods to a
closed-source product.
--kyler
------------------------------
From: Arthur Rinkel <[EMAIL PROTECTED]>
Subject: Powering on terminal
Date: Mon, 3 May 1999 16:07:37 +0200
Hi, how do I configure Linux so that when I turn on my terminal (DEC
VT320) I always get a login prompt on that terminal? In that case, Linux
is always running, and the terminal is turned on, turned off etc.
If the terminal is turned off for 15min or something, I have to HUP
the tty prg of the terminal, to get the prompt to return on the terminal's
screen. That's not what I want; no matter how long the terminal is turned
off, when you turn it on the prompt should always return. How do I do that
in a fashioned way?
Grtz, Arthur
------------------------------
From: Shimpei Yamashita <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.misc,comp.os.linux.powerpc
Subject: Re: Mac-emulation on Linux?
Date: 3 May 1999 12:24:31 +0100
FM <[EMAIL PROTECTED]> writes:
>
>I will attend a college this fall that is predominantly
>Mac-oriented. While they state that Unix and Windows are
>supported by the campus network, it seems that a Macintosh-
>compatible system might be necessary to fully take
>advantage of the system. For example, many softwares are
>written for Macintosh by the faculty, the letter for last
>year's computer purchase recommendation notes. I'm a little
>disgruntled, as I have been planning on getting a Linux
>system for college. So here are a couple of options I have:
>
>1. Just buy a X86 machine and install Linux on it (if not
>preinstalled). Get some Mac-emulation software if necessary.
>
>The problem I have with this option is that I have no idea
>about the availability of Mac-emulation softwares for Linux
>nor the degree of compatibility they provide.
Executor is an interesting piece of software, but I suspect that
not being PowerPC-ready will make it inadequate for your purposes.
If you are going to use software recently written by the faculty,
there is a strong possibility that they will no longer even compile
for the older m68k processors, which is the only processor Executor
emulates.
Also, I'm not sure if Executor is capable of becoming an AppleShare
client. I am not aware of any other Linux software that has this
capability, either. (CAP and Netatalk can do AppleShare *servers*, but
not clients.) If not, and your school has an extensive network of
AppleShare servers, then you could be seriously inconvenienced trying
to get files from those servers.
>2. Buy a Macintosh and dual boot with Linux/MacOS
>
>Well I think this is a nice compromise but I'm not sure how
>well Linux runs on Macintosh. I'm fairly sure that it will
>be an improvement over Windows/MacOS, but I'm not even sure
>if most Linux softwares are available for this setup (or if
>it's generally source-level compatible).
Source level compatibility is close to 100%. Some processor- or
hardware-dependent code will fail, but those tend to be few and far in
between. Some proprietary software is available on the PowerPC, such
as Applixware and the Motif library, although the selection is not as
big as it is on the Intel side. IMHO this is not a huge loss,
especially for students--about the only ones I really miss are
WordPerfect and Mathematica, and you can run these in Mac OS if you
are really desperate.
www.linuxppc.org is a good starting point. You should also subscribe
to the linux-pmac and linuxppc mailing lists to hear the latest
details--newsgroups are not very good indicators.
Finally, as for performance, my G3/233 was about 30% slower than a
P2/400 in most tasks except graphics (where the yet-unaccelerated
server was still relatively slow). This was a few months ago, so the
ratio may be even better today as gcc and the C library for PowerPC
are optimized for performance.
--
Shimpei Yamashita <http://www.submm.caltech.edu/%7Eshimpei/>
------------------------------
From: [EMAIL PROTECTED] (Rod Smith)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.misc,comp.os.linux.powerpc
Subject: Re: Mac-emulation on Linux?
Date: 3 May 1999 13:05:54 GMT
Reply-To: [EMAIL PROTECTED]
[Posted and mailed]
In article <7gjd3s$cdo$[EMAIL PROTECTED]>,
"FM" <[EMAIL PROTECTED]> writes:
> I will attend a college this fall that is predominantly
> Mac-oriented. While they state that Unix and Windows are
> supported by the campus network, it seems that a Macintosh-
> compatible system might be necessary to fully take
> advantage of the system. For example, many softwares are
> written for Macintosh by the faculty, the letter for last
> year's computer purchase recommendation notes. I'm a little
> disgruntled, as I have been planning on getting a Linux
> system for college. So here are a couple of options I have:
>
> 1. Just buy a X86 machine and install Linux on it (if not
> preinstalled). Get some Mac-emulation software if necessary.
>
> The problem I have with this option is that I have no idea
> about the availability of Mac-emulation softwares for Linux
> nor the degree of compatibility they provide.
As others have pointed out, Executor (http://www.ardi.com) is an option,
but it will only emulate a 680x0 Mac, which may not be enough. The last I
checked, the Executor emulation was far from perfect, too -- better than
WINE, but not phenomenal. If you can get your hands on some of the
programs you expect to be running, you can test them, since there's a
demo version of Executor available for download.
> 2. Buy a Macintosh and dual boot with Linux/MacOS
>
> Well I think this is a nice compromise but I'm not sure how
> well Linux runs on Macintosh. I'm fairly sure that it will
> be an improvement over Windows/MacOS, but I'm not even sure
> if most Linux softwares are available for this setup (or if
> it's generally source-level compatible).
My experience is with LinuxPPC Pre-R5 on an iMac. This was VERY tricky to
install, and IMHO is much more finicky and less reliable than Linux on an
x86. I don't know if this is due to LinuxPPC stuff in general or the
"beta-level" nature of the Pre-R5 release I've got. If the latter, then
I'd say that this is definitely the way for you to go. There's even talk
of a program for LinuxPPC called SheepShaver that will run Mac binaries
under Linux, but AFAIK it's not yet available.
As to Linux software, it's the rare package that won't compile for
LinuxPPC if you've got source, especially if you know a bit about
programming and can fix an occasional minor configuration problem. The
main issue in this respect is in the availability of commercial
programs. AFAIK, things like WordPerfect, StarOffice, and Accelerated-X
aren't available for LinuxPPC (ApplixWare being one major exception to
this rule). If you're not comfortable compiling source, this is a
definite drawback to LinuxPPC, but it sounds like you'll be OK with this.
You can get more information on LinuxPPC from http://www.linuxppc.org.
--
Rod Smith
[EMAIL PROTECTED]
http://www.channel1.com/users/rodsmith
NOTE: Remove the "uce" word from my address to mail me
------------------------------
From: "David Page" <[EMAIL PROTECTED]>
Subject: Re: glibc-2.1 and incompatible apps
Date: Mon, 3 May 1999 14:58:02 -0400
Reply-To: "David Page" <[EMAIL PROTECTED]>
> > 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 ?
> Arrrrgghhh!!!!
> It indeed doesn't work since the /lib/ld-linux.so.2 from glibc-2.1 refuses
> to (run-time-)link with glibc-2.0 and this path is hard coded in the
> executable.
>
> How did they manage to screw up so badly ?
Thats what I want to know. I cant even install as a test library and have
functionality. Thank GOD i did not log out!!!!
------------------------------
** 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
******************************
