Linux-Development-Sys Digest #208, Volume #8 Wed, 11 Oct 00 16:13:16 EDT
Contents:
disk quotas per directories? (Ted George)
Re: Most popular Linux development environment(s)? Graphical? (Kevin Holbrook)
Re: new windowing system (Brian Wheeler)
Re: Most popular Linux development environment(s)? Graphical? (Kevin Holbrook)
Re: task queues: slower under kernel 2.2?? ("Dan Miller")
Re: new windowing system (Steve O'Hara Smith)
3c900 full duplex problem (Mario Klebsch)
Re: Driver Loading FPGA Device (Rick Ellis)
Re: disk quotas per directories? (Alexander Viro)
Re: utime(touch) gives EPERM - Bug in Linux??? (Rick Ellis)
Re: A new directory hierarchy standard - need opinions (David Wragg)
Re: Driver Loading FPGA Device (Jonathan Buzzard)
Hard Disk Swap ("John Hall")
mapping and locking user memory ([EMAIL PROTECTED])
Re: Determining what CPU is going to execute a thread from a program ("Norman Black")
----------------------------------------------------------------------------
From: Ted George <[EMAIL PROTECTED]>
Subject: disk quotas per directories?
Date: Wed, 11 Oct 2000 10:01:03 -0500
does anyone know if the quota system for linux will be capable of
enforcing disk quotas
on a per directory basis in the future?
this would be without regard to userid or groupid. since these
directories could be added/removed on a regular basis, it would not be
feasible to have a separate partition for each directory to be
controlled. also it would be required for the same userid to have
separate quotas for different directories on the same partition.
thanks in advance.
------------------------------
From: Kevin Holbrook <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Most popular Linux development environment(s)? Graphical?
Date: Wed, 11 Oct 2000 10:04:57 -0500
MeekGeek wrote:
>
> Just to clarify this, it's a CodeWarrior lookalike, it's not based on
> any Metrowerks code.
>
Yeah they even copied our old horrible Find dialog. (ugh)
> Metrowerks sells CodeWarrior for Linux and Solaris. If you're a Mac
> developer, this is probably your best bet, on the surface. Digging
> beneath, you may find the Linux/Solaris versions are based on OLD
> versions of both CW and GNU GCC. I haven't pursued it any further
> because I've been scared off the product because of what looks like a
> lack of active support.
Yes the current selling products are a year old, however, we are
beta testing the next release - it's Pro6 just like the Mac and
Windows platforms. We have plugins for the current "officially"
released GCC, version 2.95.2.
As to the active support, I can't really comment on that.
If you want support then demand it of Metrowerks.
Call them and tell them you won't buy the product, or continue to use
the product until there is some sign of active support.
The product is being worked on, of that I'm sure. ;-)
(speaking for myself and not Metrowerks)
==============================
Kevin Holbrook
Linux Developer
Metrowerks, a Motorola Company
------------------------------
From: [EMAIL PROTECTED] (Brian Wheeler)
Crossposted-To: comp.os.linux.x,comp.windows.x
Subject: Re: new windowing system
Date: 11 Oct 2000 15:14:20 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (The Ghost In The Machine) writes:
> In comp.os.linux.development.system, Fr�d�ric G. MARAND
> <[EMAIL PROTECTED]>
> wrote
> on Wed, 20 Sep 2000 13:54:40 +0200
> <8qa8ab$jh5$[EMAIL PROTECTED]>:
>>Did you ever see an application using the X protocol directly without going
>>through the X library ? I'd be interested in any information about that.
>>
>>Alexander Viro <[EMAIL PROTECTED]> a �crit dans le message :
>>8qa7lj$[EMAIL PROTECTED]
>>> In article <[EMAIL PROTECTED]>, Aurel Balmosan <[EMAIL PROTECTED]>
>>wrote:
>>>
>>> >I must disagree. The API is the Xlib. If you write a new Xlib that IS the
>>> >X-Server X-applications wouldn't notice.
>>>
>>> _If_ your applications use Xlib. Which is almost but not quite mandatory.
>>> Besides, when was the last time you've seen X with one client?
>>[...]
>>
>>
>
> One of my employers, for performance reasons, wrote bytes directly
> to the X/socket connection. Occasionally, that lead to some
> peculiar problems, but it worked reasonably well, most of the time.
>
> I certainly wouldn't recommend it for new code unless one understood
> very well what was going on, though.
>
There's another reason: for the joy of it ;) I wrote a perl module which
wrote bytes to X...just to see if I could do it :)
I wonder what I did with that code...
Brian
------------------------------
From: Kevin Holbrook <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Most popular Linux development environment(s)? Graphical?
Date: Wed, 11 Oct 2000 10:40:55 -0500
jazz wrote:
>
> Thanks Kevin. Do you know what I can read to answer questions like the
> following?
>
> I want to develop software that will last me for years (my use only, for
> research stuff).
> I would only like to spend my time on a learning curve that will last me the
> next ten years (or so...).
>
Well I can't promise any particular software will be around for years.
It's not likely GCC will be vanishing any time soon though. And since
GCC is Apple's compiler on OS-X writing code and compiling with GCC is
a safe bet.
> Can I develop with Codewarrior for Mac OSX (not Carbon, but the Unix side)?
That really depends on how Apple made the BSD routines available and with
what language bindings and executable formats. OS-X has PEF and Mach-O images.
> Can I develop code that will be portable between Linux and OSX Unix?
Sure if you only use the same routines on both sides. Linux has most BSD
routines like OS-X.
> Using Codewarrior?
Well there is CodeWarrior for Linux and OS-X. The caveat would be the Mac
OS-X product uses it's own compiler, not gcc. The GCC plugins only ship
with the Linux/Solaris products currently.
I do know that we internally compile the same code on Mac/Windows/Linux, so
yes you can use CodeWarrior and write portable code. That issue really has more
to do with the developer than the tools.
> What would I use for graphical stuff (drawing graphs, etc.)?
>
Well this is the lousy part. OS-X has it's own graphics system, Quartz.
It's not compatible with X-Windows. You can run the XFree86 X-Server on OS-X,
but you lose Quartz, and all the Mac apps.
QuickDraw is only available under Carbon, and again is not available anywhere
else.
There is a commercial product which will make a X-Server available to run under
Quartz,
so if you wrote an X-Windows app you could run it on OS-X. It's made by Tenon
Systems.
You would have to check what development libaries they will provide however.
Someone will hopefully make the Gnome/GTK libraries work with Quartz some day
and life
will be good. ;-)
===============================
Kevin Holbrook
Linux Developer
Metrowerks, a Motorola Company
------------------------------
From: "Dan Miller" <[EMAIL PROTECTED]>
Subject: Re: task queues: slower under kernel 2.2??
Date: Wed, 11 Oct 2000 09:11:43 -0700
"Andi Kleen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Dan Miller" <[EMAIL PROTECTED]> writes:
>
> > I have a driver that I'm porting from kernel 2.0.36 to 2.2.12. The
receive
> > ISR uses a task queue to schedule copying of a data buffer from our PCI
card
> > to kernel memory.
> >
> > I have a high-speed timer card that lets me take system measurements
with 5
> > usec resolution. Under kernel 2.0, the time between calling
> > queue_task(&info->task, &tq_immediate) until the BH handler was called
ran
> > from 13 to 700 usec, average 150 usec. However, under kernel 2.2, this
time
> > runs 13 to 5200 usec, average 250!!! Why is it so much slower?? My
overall
> > data transfer rates are about 7% slower, and this is the only difference
I
> > can find (at least, within my driver), so I'm suspecting that this is
the
> > cause of my problem...
> >
> > Alternately, is there some other mechanism other than task queues that I
can
> > use to signal a BH handler, without having such a delay??
>
> First your terminology seems to be completely confused. A task queue and a
> BH are different things.
>
> If you want to make sure that IMMEDIATE_BH is executed as soon as possible
> you probably need a mark_bh(IMMEDIATE_BH) in the interrupt handler.
>
I certainly am aware that there is a difference between a task queue and a
BH handler. I'm using a task queue to schedule later execution of a BH
handler, as Linux ISRs typically do. I of course am using mark_bh(),
otherwise the function wouldn't work at all.
Does anyone have any insights into the issues that I actually asked about in
my original message?? Why is there such a longer delay from scheduling the
task queue, until the bh handler (which was scheduled by the task queue) is
actually executed, in kernel 2.2, as opposed to kernel 2.0 ???
Dan Miller
------------------------------
From: [EMAIL PROTECTED] (Steve O'Hara Smith)
Crossposted-To: comp.os.linux.x,comp.windows.x
Subject: Re: new windowing system
Date: 11 Oct 2000 16:46:52 GMT
Brian Wheeler ([EMAIL PROTECTED]) wrote:
: In article <[EMAIL PROTECTED]>,
: [EMAIL PROTECTED] (The Ghost In The Machine) writes:
: > In comp.os.linux.development.system, Fr�d�ric G. MARAND
: > <[EMAIL PROTECTED]>
: > wrote
: > on Wed, 20 Sep 2000 13:54:40 +0200
: > <8qa8ab$jh5$[EMAIL PROTECTED]>:
: >>Did you ever see an application using the X protocol directly without going
: >>through the X library ? I'd be interested in any information about that.
There is a Java based X client library that does just this.
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: 3c900 full duplex problem
Date: Wed, 11 Oct 2000 19:20:14 +0200
Hi!
I have a 3Com 3c900 ethernet card and use the 3c59x driver. It worked
fine for over a year. But recently, I got an ethernet switch and now,
problems are arising. The switch switches the port to 10 MBit full
duplex.
In full duplex mode, It seems, I am loosing ethernet datagrams. When I
do FTP test transfers to a PC running Windows 3.1, the troughput
decreases from about 750 Kyte/second to about 300 KBytes/second.
When I use a HP workstation running HP-UX 10.20, my FTP session
freezes during the 13 MByte file transfer, while it achieves easily
800 KByte/second, when the linux box uses half duplex.
Just to make it complete: I was using Linux 2.0.36 and after I
discovered these problems, I upgraded to 2.2.16. The change of the
kernel did not influence my problem at all.
Has anybody observed problems like this before? Is is a software error
in my linux system, or is it a bug in the switch? Does anybody know,
how to disable full duplex with the 3c59x driver?
thanks in advance,
Mario
--
Mario Klebsch [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
------------------------------
From: [EMAIL PROTECTED] (Rick Ellis)
Subject: Re: Driver Loading FPGA Device
Date: 11 Oct 2000 17:46:50 GMT
In article <8s06v2$oep$[EMAIL PROTECTED]>,
Jeff Andre <[EMAIL PROTECTED]> wrote:
>Is there a way of releasing that lock so the other processor can continue
>working? I've been thinking about scheduling an immediate task to handle
>the loading. However, using /proc looks like an interesting solution.
Just call schedule() inside the loop.
--
http://www.fnet.net/~ellis/photo/
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: disk quotas per directories?
Date: 11 Oct 2000 13:51:02 -0400
In article <[EMAIL PROTECTED]>, Ted George <[EMAIL PROTECTED]> wrote:
>does anyone know if the quota system for linux will be capable of
>enforcing disk quotas
>on a per directory basis in the future?
It doesn't make any sense. 1001st time, directories do not contain files.
They refer to files. There is no such thing as "directory this file belongs
to". Period. Moreover, there is no way to find all directories refering to
file other than full scan of directory tree. And to do that reliably you
should block all namespace-changing operations for the duration of such
scan. Moreover, at any moment there may be any amount of files _not_ refered
from any directory at all - open a file, unlink it and it will exist until
you close the thing.
IOW, per-directory quota makes no sense on any UNIX.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (Rick Ellis)
Subject: Re: utime(touch) gives EPERM - Bug in Linux???
Date: 11 Oct 2000 17:55:45 GMT
In article <[EMAIL PROTECTED]>,
Dr. Peer Griebel <[EMAIL PROTECTED]> wrote:
>I just discovered that I can't successfully "touch" a file (I don't
>own the file):
>
> > ls -l myfile
> -rw-rw-rw- 1 ralph users 123 Okt 10 13:46 myfile
> > touch myfile
> touch: myfile: operation not permitted
>
>As you can see the file has write permission (the directory also). But
>the file belongs to somebody else - not me. This error occurs in
>2.2.10, in 2.2.14 - but not in 2.0.36.
You need write permission for the directory entry not the file itself.
--
http://eeek.borgchat.net/linux
------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.admin,comp.os.linux.networking,comp.os.linux.setup
Subject: Re: A new directory hierarchy standard - need opinions
Date: 10 Oct 2000 14:18:00 +0000
[EMAIL PROTECTED] (The Ghost In The Machine) writes:
> 2. NFS is easily sniffable, as it does not have cryptographic capability
> as far as I know. This may be addressed sometime in the future,
> and there may be good replacements for NFS that do have crypto.
> I certainly hope so, but I haven't looked.
It was addressed sometime in the past. RFC2203, which specifies the
RPCSEC_GSS security flavour for ONC RPC (which NFS sits on top of), is
dated September 1997. RFC2623 goes into more detail about applying
RPCSEC_GSS to NFS.
Solaris has implemented this since 2.6 I think, with Diffie Hellman
public key encryption as the security mechanism. 2.8 (maybe 2.7 too?)
can also use Kerberos v5 as the security mechanism.
The group (at the University of Michigan?) doing the Sun-sponsored
NFSv4 implementation for Linux were implementing RPCSEC_GSS as a part
of that.
David Wragg
------------------------------
From: [EMAIL PROTECTED] (Jonathan Buzzard)
Subject: Re: Driver Loading FPGA Device
Date: Wed, 11 Oct 2000 00:18:44 +0100
In article <8rv6ri$1r2$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] writes:
> In article <[EMAIL PROTECTED]>,
> Arne Driescher <[EMAIL PROTECTED]> wrote:
>> Pete Zaitcev wrote:
>> >
>> > On Mon, 09 Oct 2000 18:03:20 GMT, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>> > > One of the first tasks the driver I am writing must do is to read
> a .pof
>> > > file off of the system disk and program a FPGA device on the
> device
>> > > board. This is for a PCI device but I am not sure that is
> relevant to
>> > > this situation. Does anyone have or know of any code that
> implements
>> > > this?
>> > >
>> > > Thank you.
>> >
>> > This is normally done with a helper application. The application
>> > reads the file, then issues an ioctl() into the driver that programs
>> > the FPGA.
>> >
>> > --Pete
>>
>> This is certainly a good way. However, soemtimes this is not optimal
> to
>> the purpose.
>> For the final driver version you would rather try to provide a ready
> to
>> run solution
>> without extra overhead for the installation.
>> Way 1): Write a script to convert your .pof file into a hexdump and
> link
>> it to
>> the driver. See
>> http://ifatwww.et.uni-magdeburg.de/~arne/me2600/index.htm for
>> an example.
>> Way 2) See /usr/src/linux/drivers/sound/sound_firmware.c for how to
>> load files from kernel space.
>>
>> -Arne
>>
>
> Thanks to all for your input.
>
> Our home grown board has two devices on it a CPLD (that will be
> programmed by the time I get it) and an Altera FPGA EPF10K100A (to be
> programmed). We will have a .pof file on the system disk that needs to
> be written across the PCI interface, the CPLD program contains a serial
> interface emulation to clock the .pof image into the FPGA a byte at a
> time. This provides a dynamic aspect to the board.
>
> This is the first time we are trying this, previously there was a EEprom
> with the image for the FPGA and no OS.
>
Could you not use two modules one to program the FPGA and one for the
driver. Alternatively what happens if you include it in the initialization
routines as a local variable and mark it with __initfunc? Will the
kernel free the memory used by the variable one initialised?
JAB.
--
Jonathan A. Buzzard Email: [EMAIL PROTECTED]
Northumberland, United Kingdom. Tel: +44(0)1661-832195
------------------------------
From: "John Hall" <[EMAIL PROTECTED]>
Subject: Hard Disk Swap
Date: Wed, 11 Oct 2000 19:20:36 GMT
I'm using some removeable hard drive racks to swap a 40 gig backup volume
out once a week. I don't want to restart the system; so I'm swapping hot.
I wrote some scripts to shut down all the services that are using the drive,
unmount it, then put the drive itself to sleep using "hdparm -Y /dev/hdx"
There's also a feature in the man page for hdparm " -f " that flushes the
buffer cache of the drive; I would like to do this when i put the new drive
in : "hdparm -f /dev/hdx" before I mount it etcetera. Unfortunately, I am
well aware that sometimes features listen in man pages outlive the actual
features in applications - and when I do this "hdparm -f /dev/hdx" it
returns quietly to the prompt. For other functions it gives me a status
afterward; in this case it does not.
What i'm really asking is, does this feature still work? Does it do what it
says it's doing? Is there a way to check?
I know of two other ways to accomplish this very simply; there's always
"e2fsck -F /dev/hdx" but it seems like the hdparm buffer flush would be more
elegant. The other way is to put the ide drivers into modules and rmmod them
and insmod them. Unfortunately my root FS is also on an IDE drive and I
would have to get clever to make that one work.
Any insight here? Thanks in advance.
------------------------------
From: [EMAIL PROTECTED]
Subject: mapping and locking user memory
Date: Wed, 11 Oct 2000 19:30:17 GMT
Hi,
how can I map and lock user memory in my module(driver). I have to
access the data inside a spinlock and so must ensure that the user data
is in non-paged or page-locked memory.
Iam using redhat 6.2 (kernel version 2.2.14).
I tried to use map_user_kiobuf (but this function doesn't seem to be
exported).
I read that it(locking user memory in module) can be done by adding a
kernel patch. Is their any way to do it without adding kernel patch
regards
jeseem
mailto:[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Norman Black" <[EMAIL PROTECTED]>
Subject: Re: Determining what CPU is going to execute a thread from a program
Date: Wed, 11 Oct 2000 13:06:41 -0700
Reply-To: "Norman Black" <[EMAIL PROTECTED]>
> If I let the kernel to choose what CPU to use on each thread,
>it will surely choose the same CPU for all threads because of cache
coherency issues.
Nope. The system will "try" to run a specific thread on the same CPU it
previously ran on, other than that the scheduler cannot make any assumptions
about threads within a process. "try" means that the scheduler will give
preference to a given CPU but will use others if the preferred one is not
available and another processor is available. The actual algorithms go
further than this, but you see the direction being taken.
--
Norman Black
Stony Brook Software
the reply, fubar => ix.netcom
"Miguel Angel Rodriguez Jodar" <[EMAIL PROTECTED]> wrote in
message news:8rvst5$4qk$[EMAIL PROTECTED]...
>
> Norman Black escribi� en mensaje <8rvr2e$bvq$[EMAIL PROTECTED]>...
> >> Is possible to indicate to the kernel which CPU, in a multiprocessor
> >system,
> >> must accept a thread we want to launch using fork(), clone() or
> >> phread_create() or whatever?
> >
> >Generally it is best to let the system(kernel) choose how to run the
> >available threads in the system. It understands the dynamics of
everything
> >in the system and can make the best overall choices for making full
> >utilization of available resources (processors and threads).
>
> I undestand your point, but in fact, what I want to do is a study of the
> impact of several processes running on different CPU's. Consider for
> instance a massive paralell program consisting on several threads inside
the
> same process. If I let the kernel to choose what CPU to use on each
thread,
> it will surely choose the same CPU for all threads because of cache
> coherency issues. If I write the program with care, I can avoid these
issues
> and therefore, I can exploit the paralellism at a higher rate that the
> system allows, or at least, this is what I want to proof.
>
> Miguel Angel
>
>
>
------------------------------
** 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
******************************
