Re: history of mrproper
Mr. Proper On Tue, 3 Jul 2001, Mike Sklar wrote: > > Hopefully someone could enlighten me on the history of mrproper. I think > its a great name for making sources *proper*. In particular I'd like to > know what the *mr* might stand for. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: When the FUD is all around (sniff).
It's amazing what masquerades as news. It's also noteworthy that they didn't bother to have a native speaker of English to edit the article: An executive of another affiliated company said that he felt the passion of IBM, which is determined to invest US$1 billion, this year alone, in Linux. "IBM's passion really dragged us into this movement," he added. He also said: "I can get a glimpse of the strong will of IBM, which has recently regained its business strength, with an indication that 'there shall be no free ride on Linux to be enhanced by IBM investing a huge amount of money.' On Tue, 26 Jun 2001, Jonathan Corbet wrote: > The Repubblica article was bad enough, but if you want serious kernel FUD > you should see this bit of delight on AsiaBizTech: > > http://www.nikkeibp.asiabiztech.com/wcs/leaf?CID=onair/asabt/fw/133671 > > For example: > > Also, the casual attitude of Torvald [sic], which doesn't meet the > needs of the market and minds of investors, is one of the reasons that > investors have rapidly lost interest in Linux distributors and > Linux-related businesses. > > Cool. Linus caused the end of the stock bubble... > > jon > > Jonathan Corbet > Executive editor, LWN.net > [EMAIL PROTECTED] > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3com Driver and the 3XP Processor
So it would seem. Here is the polite message I received in response my inquiry regarding the crypto interface to the card: > > > Thank you for your inquiry. We do not offer the > technical spec;s for the IPSec > features of this NIC, due to the intellectual > property-heavy nature of this > product. We will, however, be releasing a Linux > driver which supports this > feature in the very near future under the beta > section of our support site. The > base driver for the 990 will be open source, the > advanced driver (offloads, > etc.) will not be open source. Hope that somewhat > helps you. On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote: > Erm, that is going to be a problem. Crypto benifits more from open source > than any other market segment, and binary only drivers for linux are not > the way to go. I guess I need to get rid of my 5-10 3cr990s and replace > them with someone else's product? > Nick > > On Thu, 14 Jun 2001, Kip Macy wrote: > > > IPsec support will be binary only. > > As I mentioned previously IP heavy is a euphemism for commodity. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3com Driver and the 3XP Processor
IPsec support will be binary only. -Kip On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote: > So what is the truth to the rumors 3com was throwing around about the > "linux driver with ipsec support"? > Nick > > On Thu, 14 Jun 2001, Martin Moerman wrote: > > > > > > > On Thu, 14 Jun 2001, Brent D. Norris wrote: > > > > > > Now, if the NIC were to integrate with OpenSSL and offload some of THAT > > > > donkey work... Just offloading DES isn't terribly useful, as Pavel says: > > > > apart from anything else, DES is a bit elderly now - SSH using 3DES or > > > > Blowfish etc... How dedicated is this card? Could it be used to offload > > > > other work? > > > > > > Sorry my bad it is 3DES that they have on it, but I don't know how > > > in-grained it is in it. Like I sad it just floated across my desk a few > > > days ago and it sounded like a cool bit of hardware. > > > > > > The card is offloading TCP/IP checksums, TCP/IP packet fragmentation, and > > does IPSEC through the ARM9 proc. > > > > I like the card. but no real real linux drivers yet. only basic network > > card drivers for linux. > > > > /Martin > > [EMAIL PROTECTED] > > > > > > > > > > > > Brent Norris > > > > > > Executive Advisor -- WKU-Linux > > > > > > System Administrator -- WKU-Center for Biodiversity > > > Best Mechanical > > > > > > W: 270-745-8864 > > > H: 270-563-9226 > > > > > > "The problem with the Linux learning curve is that it is _so_ steep once > > > at the top you can't see the people at the bottom" --Doug Hagan > > > > > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > the body of a message to [EMAIL PROTECTED] > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: threading question
For heavy threading, try a user-level threads package. -Kip On Tue, 12 Jun 2001 [EMAIL PROTECTED] wrote: > Hello, > > due to the nature of the problem (a pairwise mutual alignment of n > sequences results in mx. n^2 alignments which can each be done in a > separate thread), I need to create and destroy the threads frequently. > > I am not really comfortable with 1.4 - 1.5 speedups since the solution was > intended as a Linux one primarily and it just happenned that it works (and > now even better) on Solaris/SGI/OSF... > > Best regards, > Ognen > > On Tue, 12 Jun 2001, Christoph Hellwig wrote: > > > In article <[EMAIL PROTECTED]> you wrote: > > > On dual-CPU machines the speedups are as follows: my version > > > is 1.88 faster than the sequential one on IRIX, 1.81 times on Solaris, > > > 1.8 times on OSF/1, 1.43 times on Linux 2.2.x and 1.52 times on Linux 2.4 > > > kernel. Why are the numbers on Linux machines so much lower? > > > > Does your measurement include the time needed to actually create the > > threads or do you even frequently create and destroy threads? > > > > The code for creating threads is _horribly_ slow in Linuxthreads due > > to the way it is implemented. > > > > > It is the > > > same multi-threaded code, I am not using any tricks, the code basically > > > uses PTHREAD_CREATE_DETACHED and PTHREAD_SCOPE_SYSTEM and the thread stack > > > size is set to 8K (but the numbers are the same with larger/smaller stack > > > sizes). > > > > > > Is there anything I am missing? Is this to be expected due to Linux way of > > > handling threads (clone call)? I am just trying to explain the numbers and > > > nothing else comes to mind > > > > Linuxthreads is a rather bad pthreads implementation performance-wise, > > mostly due to the rather different linux-native threading model. > > > > Christoph > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: threading question
This may sound like flamebait, but its not. Linux threads are basically just processes that share the same address space. Their performance is measurably worse than it is on most commercial Unixes and FreeBSD. They are not, or at least two years ago, were not POSIX compliant (they behaved badly with respect to signals). The impoverished implementation of threads is not an accidental oversight, threads are not looked upon favorably by most of the core linux kernel hackers. A quote from Larry McVoy's home page attributed to Alan Cox illustrates this reasonably well: "A computer is a state machine. Threads are for people who can't program state machines." Sorry for not being more helpful. -Kip On Tue, 12 Jun 2001 [EMAIL PROTECTED] wrote: > Hello, > > I am a summer student implementing a multi-threaded version of a very > popular bioinformatics tool. So far it compiles and runs without problems > (as far as I can tell ;) on Linux 2.2.x, Sun Solaris, SGI IRIX and Compaq > OSF/1 running on Alpha. I have ran a lot of timing tests compared to the > sequential version of the tool on all of these machines (most of them are > dual-CPU, although I am also running tests on 12-CPU Solaris and 108 CPU > SGI IRIX). On dual-CPU machines the speedups are as follows: my version > is 1.88 faster than the sequential one on IRIX, 1.81 times on Solaris, > 1.8 times on OSF/1, 1.43 times on Linux 2.2.x and 1.52 times on Linux 2.4 > kernel. Why are the numbers on Linux machines so much lower? It is the > same multi-threaded code, I am not using any tricks, the code basically > uses PTHREAD_CREATE_DETACHED and PTHREAD_SCOPE_SYSTEM and the thread stack > size is set to 8K (but the numbers are the same with larger/smaller stack > sizes). > > Is there anything I am missing? Is this to be expected due to Linux way of > handling threads (clone call)? I am just trying to explain the numbers and > nothing else comes to mind > > Best regards, > Ognen Duzlevski > -- > [EMAIL PROTECTED] > Plant Biotechnology Institute > National Research Council of Canada > Bioinformatics team > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3com Driver and the 3XP Processor
I think that they are relatively friendly. However, if they publish the interface to their card another company could come along with a card with the same functionality and take advantage of pre-existing drivers and undercut their price, thus taking away their margins. At least that is the rationale I have been given and this has occurred on at least one occasion to Adaptec. My opinion is that if you have to obscure your interface to protect your margins because you are making a commodity component then you are in the wrong business. Nonetheless they can correctly point out that they are still making a lot more money than I am :-). -Kip On Mon, 11 Jun 2001, Brent D. Norris wrote: > I thought 3com was pretty friendly to the Linux Community, was that a > misconception? > > > It can't because 3com hasn't implemented in the driver and they won't > > publish the interface. > > -Kip > > > > Brent > > Executive Advisor -- WKU-Linux > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3com Driver and the 3XP Processor
It can't because 3com hasn't implemented in the driver and they won't publish the interface. -Kip On Mon, 11 Jun 2001, Brent D. Norris wrote: > I just had one of the "3com Etherlink 10/100 PCI NIC with 3XP processor" > float accross my desk, I was wondering how much the linux kernel uses the > 3xp processor for its encryption offloading and such. According to the > hype it does DES without using the CPU, does linux take advantage of that? > > Brent Norris > > Executive Advisor -- WKU-Linux > > System Administrator -- WKU-Center for Biodiversity > Best Mechanical > > W: 270-745-8864 > H: 270-563-9226 > > "The problem with the Linux learning curve is that it is _so_ steep once > at the top you can't see the people at the bottom" --Doug Hagan > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Looking for device to write device driver for
This may well be a question whose appropriate response is RTFM. However, I did look first. I am taking a class on writing device drivers for Linux. I am currently looking for a device to write a driver for. I first tried to get the engineering specification for my soundcard, but after much frustration I gave up on dealing with the manufacturer. I then tried to get the interface information from 3com on their new 3cr990 card to add IPsec offload support to the linux driver. They responded by telling me that due to IP-heavy nature of the product that they would not be releasing the interface. It was later explained to me (in different terms) that most cards on the market are fundamentally commodity items and as such the only way that manufacturers can ensure their margins is by obscuring the interface so that other manufacturers don't use the same interface and undercut them. This leads to my question: Is there some central resource for listing unsupported cards that people have expressed an interest in seeing supported. The closest I could find was Cosource, but that is fairly limited. -Kip - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
