Linux-Development-Sys Digest #307, Volume #8 Tue, 28 Nov 00 19:13:08 EST
Contents:
Re: gcc-2.95.2 forces ALL c++ programs to be GPL !!??!#
(=?iso-8859-1?Q?J=F6rgen_Tegn=E9r?=)
Re: Software RAID ("Deanna Bonds")
Re: nvidia kernel module under 2.4.0-test11 ("T. J. Domsalla")
Portable way of accessing PCI device from user space ("Slawek Grajewski")
Re: gcc-2.95.2 forces ALL c++ programs to be GPL !!??!# (Stefaan A Eeckels)
Re: hi, i need some help with a parallel port (Glitch)
Re: hi, i need some help with a parallel port (Glitch)
Re: gcc-2.95.2 forces ALL c++ programs to be GPL !!??!# ([EMAIL PROTECTED])
Kernel preemption - socket handling (Rui Antunes)
Re: I admit it! (Nix)
Re: Runtime file size modifying (Nix)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (=?iso-8859-1?Q?J=F6rgen_Tegn=E9r?=)
Subject: Re: gcc-2.95.2 forces ALL c++ programs to be GPL !!??!#
Date: Tue, 28 Nov 2000 20:06:18 +0100
In article <9007fu$ijo$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Ok folks,
>
>I've just finished as rigorous an analysis as I've yet seen of the
>licensing issues surrounding C++ programs compiled with the GCC
>compiler.
>
>The bottom line is that since C++ programs statically link in
>libstdc++.a and the libstdc++.a library includes 2 files (./gcc-
>2.95.2/include/ansidecl.h and ./gcc-2.95.2/texinfo/lib/strerror.c)
>that fall under GPL (not LGPL or special exceptions), therefore these
>files must either be removed or the rest of the executable's source
>must be made freely available to the public. This would seem to apply
>to all C++ programs compiled with gcc-2.95.2.
[snip]
This is from the info page of g++. Did you take this into consideration
when writing your report? I could not read it, no pdf reader here.
For certain portions of libg++ that implement required parts of the
C++ language (such as iostreams and other standard classes), the FSF has
loosened the copyright requirement still more by adding the "special
exception" clause, which reads as follows:
As a special exception, if you link this library with files
compiled with GCC to produce an executable, this does not cause
the resulting executable to be covered by the GNU General Public
License. This exception does not however invalidate any other
reasons why the executable file might be covered by the GNU
General Public License.
If your only use of libg++ uses code with this exception, you may
ship stripped executables or license your executables under different
conditions without fear of violating an FSF copyright. It is the intent
of FSF and Cygnus that, as the other classes required by the ANSI/ISO
draft standard are developed, these will also be placed under this
"special exception" license. The code in the new libstdc++ library,
intended to implement standard classes as defined by ANSI/ISO, is also
licensed this way.
--
J�rgen Tegn�r
Message created with 100% recycled electrons.
------------------------------
From: "Deanna Bonds" <[EMAIL PROTECTED]>
Subject: Re: Software RAID
Date: Tue, 28 Nov 2000 12:03:13 -0500
Crossposted-To: comp.os.linux.hardware,alt.linux,comp.os.linux.misc
Hey
I am the person at Adaptec that is responsible for the driver for the 2100s.
I must say that the performance test numbers may be somewhat skewed due to
problems with the driver. When I took responsibility for the I2O RAID
driver I noticed a few major performance bottlenecks. I almost have
rewritten the driver in the next upcoming release to remove these
bottlenecks. There should be a significant performance increase. I would
hold off making any tactical decisions on hardware vs. software until after
some performance numbers can be taken with the new driver.
Also as a side note, disk io is not the only performance numbers that
should be considered. CPU utilization of software RAID will slow the
overall performance of the machine. For some this may not be noticeable,
but if you really load down your computer you will notice a difference.
Deanna
"Warren Young" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] wrote:
> >
> > First let me say I know NOTHING about software RAID in Linux.
>
> It was not necessary to make this statement. It is self-evident.
>
> > That said, I have a server with Software RAID on a SUN running Solaris,
> > and I would never inflict Software RAID on another machine as long as I
> > live. Hardware RAID can hide a lot of things from the user, and be just
> > about as 'fast' as an individual disk. Software RAID is going to slow
> > your disk writes, well REALLY BAD.
>
> Your mistake is in applying your Solaris experience to Linux, which is
> always a mistake. (Speaking as one who has used Solaris' cousin
> UnixWare for years.)
>
> Take it from one who has actually done benchmarks of software vs.
> low-end hardware RAID (the Adaptec 2100S): Linux's software RAID is
> impressively fast. In many cases, it's much faster than the hardware
> RAID. (In particular, RAID 0 is much faster in software.)
>
> Part of this is no doubt because my system has a 500 MHz processor and
> the RAID card only has a 66 MHz (?) processor. In the bad old days of
> double-digit main CPUs, hardware RAID might have done better against
> software RAID.
>
> Let's also not forget that people call it "Slowaris" for a reason...
> --
> = Warren -- ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
------------------------------
From: "T. J. Domsalla" <[EMAIL PROTECTED]>
Subject: Re: nvidia kernel module under 2.4.0-test11
Date: Tue, 28 Nov 2000 21:41:23 +0100
Hi,
>> NVIDIA GeForce graphics card. [...]
>> I have got a version which is claimed to compile on 2.3.x but
>> it fails on 2.4.0-test11. [...]
> go to irc.openprojects.net #nvidia !
Is there a way to solve the problem without going into IRC?
TJ
------------------------------
From: "Slawek Grajewski" <[EMAIL PROTECTED]>
Subject: Portable way of accessing PCI device from user space
Date: Tue, 28 Nov 2000 21:51:22 +0100
Hello,
I've a question - how should I access PCI device from user space in a
protable way? Is it possible at all? If yes, then how?
As far as I know, on i386 architecture, it is just mmap and I can directly
write to the PCI device memory. What about other architectures? Is it
portable?
Thanks,
Slawek
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Subject: Re: gcc-2.95.2 forces ALL c++ programs to be GPL !!??!#
Date: Tue, 28 Nov 2000 22:07:05 +0100
In article <9007fu$ijo$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] writes:
> The bottom line is that since C++ programs statically link in
> libstdc++.a and the libstdc++.a library includes 2 files (./gcc-
> 2.95.2/include/ansidecl.h and ./gcc-2.95.2/texinfo/lib/strerror.c)
> that fall under GPL (not LGPL or special exceptions), therefore these
> files must either be removed or the rest of the executable's source
> must be made freely available to the public. This would seem to apply
> to all C++ programs compiled with gcc-2.95.2.
My C++ programs don't link statically to libstdc++. I'm puzzled
as to why you and your informants seem to believe this library
needs to be linked statically.
Take care,
--
Stefaan
--
Ninety-Ninety Rule of Project Schedules:
The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.
------------------------------
Date: Tue, 28 Nov 2000 16:28:09 -0500
From: Glitch <[EMAIL PROTECTED]>
Subject: Re: hi, i need some help with a parallel port
I've found out by reading the IO port howto that the values in the outb
function were reversed. This was the fault of not knowing the correct
order myself and just going by what the person did who made the webpage
i was following. I found out that DOS uses the order I had used but
Linux does it in reverse order.
I made that change last night and i dont get the compiler warning
anymore and even teh segfault has disappeared however nothing appears on
the LEDs of the custom board.
My prof. said that the board is using 0x300 but i found out my sound
card was using that address. He said I could goto Intel's site to get
the info on the P8255A chip to set teh dip switches to use another
address but i found no info on that chip on INtel's site. I did however
remove my sound card and used DOS's debug command to send bytes to
address 300 and then read from that same port but the bytes I got back
were always FF whether I sent 11 or aa to the port. Windows recognizes
that an unknown device is using address 300 but for some reason I'm not
receiving the same bytes I'm sending to the port using DEBUG.
As I don't know which dip switches to set to change the address the
board uses I'm unable to use the 0x80 idea.
I was not sure what the compiler warning meant b/c as far as I knew at
that time I was using the outb function properly and did not think that
the values were in the wrong order. I used asm/io.h b/c that was used in
the examples I found. I have not done this sort of programming before
and in fact we weren't even taught this in the class this project is for
so everyone is sort of going out on a limb here with *this* particular
project (we got to choose between 5 difernt projects) project as the
class wasn't about this. However I figured I'd do it to learn something
and i thought it couldnt be that hard compared to windows as Linux
treats every device as a file. However I've realized that you can't do
that in this case as I don't know how to make Linux recognize this
'device' and to make a device node for it in /dev. The reason why i
don't know how to use /dev/port with this device is b/c i dont know how
to associate /dev/port with this device as Linux doesn't recognize it.
The only recognition i receive is from Windows telling me it knows some
kind of device is using address 0x300.
Although I doubt it will work(b/c i dont know how to associate /dev/port
with the device im using) i can try the code posted by the 2nd response
and i'll post the consequences after I try it out. i also don't know the
address to use to access the appropriate ports on this board and until i
figure that out nothing will work. I'll complain to my professor
tomorrow.
thanks for all the help
Glitch wrote:
>
> I'm doing a project for school with the parallel port. We are given a
> custom-made 'parallel' port that has LEDs on the circuit board. We are
> to send signals to the board so that the LEDs light up, in whatever
> order we want. I've found programs to do this (i'm attempting it under
> linux however I have only found one sample of this in linux code) but i
> get a compiler warning as well as a seg fault when the program is
> executed.
>
> here is the source code:
> #include <stdio.h>
> #include <unistd.h> /* needed for ioperm() */
> #include <asm/io.h> /* for outb() and inb() */
>
>
> #define DATA 0x300 /* this is what address we are told the
> custom-made board is located */
>
> int main(void)
> {
> int x = 0x32;
>
> if (ioperm(DATA,3,1)) {
> printf("Sorry, you were not able to gain access to the
> ports\n");
> printf("You must be root to run this program\n");
> exit(1);
> }
>
> outb(DATA, x); /* Sends 0011 0010 to the Data Port */
> return (0);
> }
>
> Now after some reading i know i have to compile with the -O option b/c
> of the outb function. I do that but receive this warning: large integer
> implicitly truncated to unsigned integer. As this is a warning I'm not
> too concerned however I get a segfault when I run the program. I use
> ltrace AND strace on it but they don't help me. THe last line of output
> for strace is ioperm(0x300, 0x3, 0x1) =0 and then it says 'killed by
> segfault'
>
> can anyone give me some pointers as to what could be wrong??
> i'd appreciate it.
------------------------------
Date: Tue, 28 Nov 2000 16:39:26 -0500
From: Glitch <[EMAIL PROTECTED]>
Subject: Re: hi, i need some help with a parallel port
btw, the code below, except for some small snippets, makes no sense to
me as i'm not a device programmer or anything like that. I'm a simple
programmer and haven't used hardly anything in this program except the
basics like the printf and if statements. As such I probably won't be
able to use this code as I'd like to also understand why it works like
it does....this seems too complicated. Way over my head.
My original code was ok but this stuff below looks like too much to do
something simple (at least I thought it was simple). Maybe i'll just do
it in Windows. It can't be any harder that way than it has already
become.
Pete Zaitcev wrote:
>
> On Tue, 28 Nov 2000 00:48:35 -0500, Glitch <[EMAIL PROTECTED]> wrote:
>
> > here is the source code:
> > #include <stdio.h>
> > #include <unistd.h> /* needed for ioperm() */
> > #include <asm/io.h> /* for outb() and inb() */
> ^^^^^^^^^^^^^^^^^^^^^^^
> First thing is my pet peeve. You are not supposed to use <asm/io.h>
> in an application code. Your code WILL work if you do, but by pure
> luck (because such is i386 implementation). You must copy the definition
> over to your application. Better yet, use /dev/port - I have an example
> attached.
>
> > #define DATA 0x300 /* this is what address we are told the
> > custom-made board is located */
> ^^^^^^^^^^^^^^^^^^^^^^^
> For more fun, place it on 0x80
>
> > int main(void)
> > {
> > int x = 0x32;
> >
> > if (ioperm(DATA,3,1)) {
> > printf("Sorry, you were not able to gain access to the
> > ports\n");
> > printf("You must be root to run this program\n");
> > exit(1);
> > }
> >
> > outb(DATA, x); /* Sends 0011 0010 to the Data Port */
> ^^^^^^^^^^^^^^^^^^
> Other poster showed you already that that your arguments are
> reversed.
>
> > return (0);
> > }
> >
> > Now after some reading i know i have to compile with the -O option b/c
> > of the outb function. I do that but receive this warning: large integer
> > implicitly truncated to unsigned integer. As this is a warning I'm not
> > too concerned however I get a segfault when I run the program. I use
>
> That will teach you to pay attention to compiler warnings :)
> Of course, 0x300 cannot fit into byte because your arguments
> were reversed.
>
> --Pete
>
> P.S. Here is the promised example, ripped off from real code
> (look ma, no hands! no ioperm! no <asm/io.h>!):
>
> -------------------------------------------------------------
> /*
> * Test of alpha-blending on IGS5000
> */
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <errno.h>
> #include <string.h>
> #include <fcntl.h>
> #include <unistd.h>
> #include <ctype.h>
>
> #define NAME "alphu"
>
> void xioinit(void);
> unsigned int xinb(unsigned int port);
> void xoutb(unsigned int val, unsigned int port);
>
> int
> main(int argc, char *argv[])
> {
> unsigned char chipid[3];
> unsigned char b;
> // struct par par0;
>
> // params(&par0, argc, argv);
>
> xioinit();
>
> /*
> * Read the chip ID. This is to make sure we have the board.
> * For IGS 5050 the ID yields A3:0B:00.
> */
> xoutb(0x91, 0x3ce);
> chipid[0] = xinb(0x3cf);
> xoutb(0x92, 0x3ce);
> chipid[1] = xinb(0x3cf);
> xoutb(0x93, 0x3ce);
> chipid[2] = xinb(0x3cf);
> printf("IGST Chip ID: %02x:%02x:%02x\n", chipid[0],chipid[1],chipid[2]);
> /* Comment out this piece if you know what you are doing. */
> if (chipid[0] != 0xa3 || chipid[1] != 0x0b) {
> fprintf(stderr, NAME ": chip ID mismatch\n");
> exit(1);
> }
>
> ...................................
>
> /* P3 */ printf("Done.\n");
> exit(0);
> return 0;
> }
>
> #if DEVPORT
>
> // OK, this is bad. Gotta have a class and xioyyy() a member XXX
> static int xiofd;
>
> void
> xioinit() {
> int fd;
>
> if ((fd = open("/dev/port", O_RDWR)) == -1) {
> fprintf(stderr, NAME ": Cannot open /dev/port: %s\n",
> strerror(errno));
> exit(1);
> }
> xiofd = fd;
> }
>
> unsigned int
> xinb(unsigned int port) {
> unsigned char val;
>
> if (lseek(xiofd, (off_t)port, SEEK_SET) == (off_t)-1) {
> fprintf(stderr, NAME ": Cannot seek to %u\n", port);
> exit(1);
> }
> if (read(xiofd, &val, 1) != 1) {
> fprintf(stderr, NAME ": Cannot read from %u\n", port);
> exit(1);
> }
> return val;
> }
>
> void
> xoutb(unsigned int val, unsigned int port) {
> unsigned char valb = val;
>
> if (lseek(xiofd, (off_t)port, SEEK_SET) == (off_t)-1) {
> fprintf(stderr, NAME ": Cannot seek to %u\n", port);
> exit(1);
> }
> if (write(xiofd, &valb, 1) != 1) {
> fprintf(stderr, NAME ": Cannot write to %u\n", port);
> exit(1);
> }
> }
>
> #endif /* DEVPORT */
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: gcc-2.95.2 forces ALL c++ programs to be GPL !!??!#
Date: Tue, 28 Nov 2000 22:54:00 GMT
In article <anv009.igi.ln@burken>,
[EMAIL PROTECTED] (=?iso-8859-1?Q?J=F6rgen_Tegn=E9r?=) wrote:
> This is from the info page of g++. Did you take this into
consideration
> when writing your report? I could not read it, no pdf reader here.
>
> For certain portions of libg++ that implement required parts of the
> C++ language (such as iostreams and other standard classes), the FSF
has
> loosened the copyright requirement still more by adding the "special
> exception" clause, which reads as follows:
>
> As a special exception, if you link this library with files
> compiled with GCC to produce an executable, this does not cause
> the resulting executable to be covered by the GNU General Public
> License. This exception does not however invalidate any other
> reasons why the executable file might be covered by the GNU
> General Public License.
>
> If your only use of libg++ uses code with this exception, you may
> ship stripped executables or license your executables under different
> conditions without fear of violating an FSF copyright. It is the
intent
> of FSF and Cygnus that, as the other classes required by the ANSI/ISO
> draft standard are developed, these will also be placed under this
> "special exception" license. The code in the new libstdc++ library,
> intended to implement standard classes as defined by ANSI/ISO, is also
> licensed this way.
Most of the files do include a "special exception" or have no license at
all. These were called out in my more detailed analysis -- which I've
now posted in html form as well within: http://briefcase.yahoo.com/rw78a
Regards,
Ralph
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Rui Antunes)
Crossposted-To: comp.os.linux.questions,alt.os.linux
Subject: Kernel preemption - socket handling
Date: Tue, 28 Nov 2000 23:27:20 GMT
I'm developping a (RH7) kernel module that intercepts the socket API
and handles sockets. I have some doubts about kernel preemption and
the (kernel) sockets.
I got this from a paper:
�The Linux kernel is monolithic. Only one thread of control created by
a system call is active at any time. This means that device drivers do
not need to lock their data structures as a general rule.�
'Only one thread of control is active at any time' or �Only one thread
of control created by a system call is active at any time�?!?
If my kernel module is running is it possible that other kernel may
run (I know that software and hardware interrupts can)?
If my kernel module handles (modifies) sockets is it necessary to use
some kind of kernel-locking mechanism to avoid race conditions
(regarding kernel functions that implement transport and network
layers)?
What kernel-locking mechanisms are available?
Thanks in advance,
Rui Antunes
[EMAIL PROTECTED]
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: I admit it!
Date: 28 Nov 2000 23:15:24 +0000
[EMAIL PROTECTED] (Kaz Kylheku) writes:
> There are GUI front ends to gdb, like xxgdb or ddd. In ddd you can plot views
> of variables on a graph-like thing. Can't speak from experience; I looked over
> the shoulder of someone who was odoing it. ;)
I can vouch for DDD. If you're developing programs with complex data
structures in, it can be *really* useful --- although, I'll admit, that
old trick of putting a formatted dumper function in your program and
calling it with `print' from gdb takes some beating. (Although as DDD is
built on top of gdb, you can do that from there as well.)
It's very good --- although I tend to use little more than breakpoints,
`info local' and `bt' in my debugging, when I *need* to mess with
watchpoints, conditional breakpoints and wandering through data
structures thinking `WTF is wrong with this?' DDD definitely does come
in handy.
--
`The phrase `causes storage to be reserved', doesn't mean that it causes
storage to be reserved. This is a fundamental misunderstanding of
Standardeze.' --- Mike Stump on the GCC list
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Runtime file size modifying
Date: 28 Nov 2000 23:49:46 +0000
[EMAIL PROTECTED] (Alexander Viro) writes:
> Huh? With the normal mount it doesn't happen - all you see is permissions
> of the covering object. The problem being: in case of unions there is no
> such thing as _the_ covering object - too many candidates/
... and you can't use the topmost one. Ouch.
> Taking the permissions of the first object in union is bogus - we need
> different treatment for different bits. Sigh...
A directory with different permissions depending on what files you
open()?!? I must be misunderstanding!
> >Still, at least it's pronounceable. (IEEIX, ugh.)
>
> <wry>
> IMO FPOSIX would be more appropriate.
> </wry>
It's a standard, and vendors had input into it, and --- most importantly
--- it did more than merely standardize existing practice. Of course it
ended up sucking in numerous amusing ways. The C standardization
committee got it pretty much right; import some nice ideas from C++,
formalize existing practice, and call it a standard. (And even they
tried the `add new bits' trick; remember `noalias'? *shudder*)
--
`The phrase `causes storage to be reserved', doesn't mean that it causes
storage to be reserved. This is a fundamental misunderstanding of
Standardeze.' --- Mike Stump on the GCC list
------------------------------
** 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
******************************
