Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Traffic #123 For 25 Jun 2001

By Zack Brown

linux-kernel FAQ | subscribe to linux-kernel | linux-kernel Archives | | LxR Kernel Source Browser | All Kernels | Kernel Ports | Kernel Docs | Gary's Encyclopedia: Linux Kernel | #kernelnewbies

Table Of Contents

Mailing List Stats For This Week

We looked at 998 posts in 3958K.

There were 426 different contributors. 184 posted more than once. 138 posted last week too.

The top posters of the week were:

1. Sony Vaio Motion Eye Camera Driver

10 Jun 2001 - 15 Jun 2001 (18 posts) Subject: "[PATCH 2.4.5-ac12] New Sony Vaio Motion Eye camera driver"

Topics: USB, Version Control

People: Stelian PopAlan CoxLinus Torvalds

Stelian Pop announced a new driver for the Sony Vaio MotionEye camera from the Picturebook models. He posted a patch and explained:

The driver does not yet support overlay (no docs... :-( ), but it does support grabbing, jpeg snapshots and mjpeg compressed videos (through a private API, documented in <file:Documentation/video4linux/meye.txt>).

Until the alcove-labs web site updates, you can download the 'motioneye' application documented in meye.txt from: and

Alan Cox asked if the hardware really supported overlay, and Stelian confirmed that it did, though he added, "even if I know how to program the mchip to output to the video bus, there is something missing to enable overlay (either in the mchip or in the ati video driver)." Alan speculated:

It could be using the YUV digital inputs to the ATI chip. It seems however also quite likely to me that windows is doing the following

  1. Issuing USB transfers which put the data into video ram overlay buffers (ie the DMA from the USB controller)
  2. Using the YUV overlay/expand hardware in the ATI card (see for X stuff for ATI for this)

Stelian agreed, but also said that after a quick look at the Gatos site, "it seems that the Rage Mobility P/M card which this laptop has isn't yet supported." Linus Torvalds replied:

It definitely is - at least if you use the XFree86 CVS tree with just the ATI video extensions imported from Gatos. I've used the YUV hardware for half-accelerated DVD playing ("half-accelerated" only because the chip can really do MC too, but ATI doesn't document how to do it, so it only does the YUV conversion).

I've not figured out why the ATI Xv stuff from gatos seems to not have made it into the XFree86 CVS tree - it works better than much of the Xv stuff for some other chipsets that _are_ in the CVS tree.

I imported it into the XFree86 CVS some months ago, it was trivial. I don't have the patches lying around any more, though. I can try to re-create them if anybody needs help.

After a bit more discussion Stelian said, "the main question remains: does the MotionEye camera support overlay or not ? It could be that it is connected to the feature connector of the ATI board for doing direct video input/output (but no X driver recognizes this connector today). The motion jpeg chip this camera is based on definately has a video output. Or it could just be the application who gets YUV data from the chip then send it directly to the video board. Today this works, almost (because we need a patched X - read gatos - and a patched xawtv - in order to do scaling)." Linus replied that he had no idea about overlay support, and the thread ended inconclusively.

2. Status Of Intel Gigabit Ethernet NIC With The TL82543GC Chipset

11 Jun 2001 - 14 Jun 2001 (12 posts) Subject: "Gigabit Intel NIC? - Intel Gigabit Ethernet Pro/1000T"

Topics: Networking, POSIX

People: Shawn StarrAlan CoxRiley WilliamsRalf BaechleJames SutherlandIon Badulescu

Shawn Starr asked about the status of Intel gigabit Ethernet NIC (copper) with the TL82543GC chipset under Linux. He said, "The sales guy who is promoting it says this is apparently a new card and he claims he can get specs from engineering." Alan Cox burst into loud peals of laughter. As these subsided, he replied, "Nobody has been able to get remotely useful docs out of intel on their 1Gbit ethernet." Riley Williams suggested, "tell the said sales guy that IF he can get you the FULL specs TOGETHER WITH permission to freely distribute them, AND "a friend of yours who knows how to read such specs" confirms that they are indeed FULL specs, then you'll consider buying some of the cards, but if not, you're not interested..." Ion Badulescu pointed out that permission to distribute the specs was not strictly necessary, as long as it was possible to distribute driver sources under the GPL. Ralf Baechle argued, "You then have a GPL'ed driver which still cannot be sanely modified in the way the GPL would like to guarantee." But James Sutherland replied, "the GPL doesn't attempt to guarantee users the INFORMATION needed to make sane changes, just that they have the facility to do so. Just as the kernel doesn't come with a copy of the POSIX specs, the RFCs, etc. - some of the standards the kernel implements aren't available publicly, but that doesn't stop the kernel being freely modifiable!" At one point Alan reiterated, "you have a better chance of getting a straight answer out of a politician than intels networking folks." At one point Shawn gave an update on his interaction with Intel, saying, "No word yet. I would be extremely surprised to get the docs WITHOUT an NDA or so. It never hurts to try though :-)"

3. Docs From 3Com

11 Jun 2001 - 18 Jun 2001 (35 posts) Subject: "3com Driver and the 3XP Processor"

Topics: PCI, SMP

People: Kip MacyAlan CoxMartin Moerman

Brent D. Norris asked about the status of the 3Com Etherlink 10/100 PCI NIC with 3XP processor under Linux; in particular Brent had heard that the card handled DES encryption without using the CPU. He asked if Linux took advantage of that, and Kip Macy replied, "It can't because 3com hasn't implemented in the driver and they won't publish the interface." Brent replied that his impression had been that 3com was fairly friendly to the Linux community. He asked if that was a misconception, and Kip said, "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." Alan Cox replied, "Crypto hardware is commodity. In fact its questionable it has any value below 1Gbit/second anyway because the cheapest low speed crypto coprocessors are made by AMD and intel. They fit into the second socket on your dual cpu motherboard and as well as being mass market are conveinently reprogrammable and able to run your applications when not doing crypto. The cheapest raid accelerator is the same story. It costs a lot of money to build custom hardwae, an x86 is the wrong solution but its sufficiently large a hamemr that it works better than the elegant approach for most cases."

At one point Martin Moerman from 3Com said, "To make it easier, Tell me exactly what you need in documentation and I will try to get it for you." There was no reply.

4. 2.4.5 Data Corruption

12 Jun 2001 - 19 Jun 2001 (14 posts) Subject: "2.4.5 data corruption"

Topics: Disks: SCSI, FS: ext2

People: Eugene CrosserAlan CoxLarry McVoy

Larry McVoy reported reproducible data corruption under 2.4.5, and Eugene Crosser also reported, "These days I observed massive FS curruption on vanilla 2.4.5, SCSI disk on Sym53c8-something controller (UW). I did not notice any problems since 2.4.5 was published, they seem to have surfaced immediately after I created a rather big file capturing video with broadcast2000 (video card is bt848). Filesystem is ext2." Alan Cox confirmed this problem. Later Larry reported that his corruption was not as reproducible as he'd first thought, and the thread petered out.

5. Linux 2.4.6-pre3

12 Jun 2001 - 14 Jun 2001 (12 posts) Subject: "Linux-2.4.6-pre3"

Topics: FS: NFS, FS: ReiserFS, FS: devfs, Framebuffer, Networking, PCI, Power Management: ACPI, USB, Virtual Memory

People: Linus TorvaldsJuff GarzikTim WaughTrond MyklebustAlexander ViroRik van RielJohannesMike GalbraithChris MasonAndrea ArcangeliPaul MenageDavid WoodhouseGeert UytterhoevenJeff GarzikKai GermaschewskiPatrick MochelPaul MackerrasAndries BrouwerMarcelo TosattiNeil BrownKeith OwensRichard GoochAndrew Morton

Linus Torvalds announce 2.4.6-pre3 and explained:

User-noticeable things: if you are tired of not being able to NFS-export your reiserfs tree, this should make you happy.

VM tuning has also happened, with Rik van Riel, Mike Galbraith, Marcelo Tosatti and Andrew Morton all doing various tweaks. Give it a whirl.

He also posted the changelog:


  1. remember to increment the version number
  2. Chris Mason: reiserfs mark_journal_new and bh leak fix
  3. Richard Gooch: devfs update
  4. Alexander Viro: further FS cleanup (superblock list)
  5. David Woodhouse: MTD update
  6. Kai Germaschewski: ISDN update (stanford checker fixes etc)
  7. Rich Baum: gcc-3.0 warning fixes
  8. Jeff Garzik: network driver updates
  9. Geert Uytterhoeven: m68k fbdev logo merge glitch fix
  10. Andrea Arcangeli: fix signal return path
  11. David Miller: Sparc updates
  12. Johannes Erdfelt: USB update
  13. Carsten Otte, Andries Brouwer: don't clear blk_size unconditionally on partition check
  14. Martin Frey: alpha Sable irq fix
  15. Paul Mackerras: PPC softirq update
  16. Patrick Mochel: PCI power management infrastructure
  17. Robert Siemer: miroSOUND driver update
  18. Neil Brown: knfsd updates, including ability to export ReiserFS filesystems
  19. Trond Myklebust: NFS readdir fixup, don't update atime on client
  20. Andrew Morton: truncate_inode_pages speedup
  21. Paul Menage: make inode quota count all inodes..

Keith Owens replied to item 8, reporting compiler warnings from the tulip driver. Jeff Garzik replied, "There are no network driver updates, including no tulip updates. The PCI API changed, there is breakage and cleanup is needed" Tim Waugh said with a frown, " a stable kernel series.. :-((" At one point Linus said:

It shouldn't have broken anything. The warning happens, but the function call ends up doing the same thing as it used to - old drivers will just ignore the new argument.

It was a necessary step in working ACPI suspend. Which Patrick has working - with caveats. And the fact that Pat happens to work at the same company I do probably has more to do with the fact that Transmeta is obviously interested in suspend issues more than most - and not so much with the fact that he would exert undue influence on me.

6. Unregistered Changes To The User<->Kernel API

14 Jun 2001 (15 posts) Subject: "unregistered changes to the user<->kernel API"

People: Andrea Arcangeli

Andrea Arcangeli reported:

There are a number of changes in kernel API visisble to userspace that are unregistered in 2.4 mainline. I recommend to merge them ASAP to avoid generating collisions across different versions of the kernel.

I'll attach here a number of patches that should make us to return in sync. They must be applied incrementally. (really the very last one is mostly here for comments, not intendeted for merging in mainline)

here the first that defines O_DIRECT (NOTE: the O_DIRECT value for alpha is not definitive yet, O_DIRECTIO of tru64 is our O_NOFOLLOW so we're just screwed as we just need a wrapper anyways to make complex programs like dbms to run correctly without having to natively port them to linux, 02000000 in tru64 is O_DSYNC, maybe I should move it to 010000000 instead which maybe unused in tru64, but still we would have no guarantee that it won't be used in the future, I was waiting Richard's comment about it).

The sparc64 values are approved by Dave.

7. IBM Lumbering Near Open Source

15 Jun 2001 - 18 Jun 2001 (14 posts) Subject: "ps2 keyboard filter hook"

People: Dan StreetmanJeff GarzikAndries BrouwerMichael RothwellMike A. Harris

Dan Streetman from IBM said:

IBM Retail Store Solutions dept has certain PS/2 keyboards which extend the standard PS/2 specification in order to support addition hardware built into the keyboard (such as a Magnetic Strip Reader, Keylock, Tone generator, extra keys, extra LEDs, etc). This addition hardware behaves in a manner that makes it unusable if driven by a standard PS/2 driver (sadly, due to the fact that its design is "IP" I can't elaborate on how or why it is incompatible with the standard PS/2 specification).

In order to use these keyboards, a the standard PS/2 driver needs to behave a bit differently; thus attached is a modifcation to the PS/2 driver which allows other drivers to register with the PS/2 driver as 'filters'. There is a arbitrary max number of 'filters' set to 1, which is a compile-time define. The registered drivers are called (in order of registration) for every scancode, and they may change or consume the scancode (or allow it to pass). Also the 'filters' are given a function to send an variable-sized buffer to the keyboard output port; this function is synchronized using a semaphore which also coordinates with pckbd_leds().

Jeff Garzik asked, "Didn't we just conclude a discussion here on linux-kernel, which said that patches which simply add hooks allowing proprietary extensions are not accepted into the kernel?" Andries Brouwer replied, "There is a certain need for this kind of patches. I have seen similar stuff for the blind, or for disabled people who for example can use only one hand. Also for people who use a combined keyboard/barcode reader. Hooks for drivers that do something special have other uses than for proprietary extensions." Elsewhere, Michael Rothwell added:

I'm facing a similar problem with the "Qoder" barcode scanner. I have to have a keyboard hook. The "right" way seem to be to use the input api. Unfortunately, this means that current kernels can't use the driver w/o a patch (the input api patch). The ugly way is to patch the keyboard driver. I'm doing both.

However, I wrote a REALLY SIMPLE hook tht supported exactly my needs, since it's in the category of "ugly hack waiting for input api." Maybe I'll write a version for your hook.

I wonder when the input api stuff for ps/2 devices will be a part of the mainstream kernel...

Dan himself also replied to Jeff, saying:

I never intended to get that patch in. In fact I would be shocked (and a bit horrified) if it was accepted.

But management doesn't listen to me when I say it will never get accepted so I had to make a token effort of submitting it to prove it won't get accepted.

And I did try hard to convince them to release the actual driver but it didn't work.

Mike A. Harris replied:

I find it very odd indeed with IBM's big voice of open source praise, yada yada, and what Lou has said in the past, that there would be any question at all of wether it would be open source or not. Isn't big blue behind open source? Or is it just for publicity? Makes me wonder now...

Must be some real good rocket science in that interface that theres no way on earth someone else could come up with it for it to be important IP to protect. Makes me wonder what's hiding behind it...

Dan replied, "I actually think that in this case (and possibly many others) it's not a case of wanting to 'protect' amazing code or design, but more that people are used to working a certain way (closed), and it's hard to change. They still have a 'reflex' that tells them to keep it closed, and need a good business (or legal) reason to open it...instead of asking 'why not?' they ask 'why?'."

8. Email Virus On linux-kernel

15 Jun 2001 - 19 Jun 2001 (9 posts) Subject: "Snowhite and the Seven Dwarfs - The REAL story!"

An anonymous attacker posted an email virus to linux-kernel and a bunch of folks just laughed at it.

9. Status Of Hotplug CPU Support

16 Jun 2001 (4 posts) Subject: "[ANNOUNCE] HotPlug CPU patch against 2.4.5"

Topics: FS: sysfs, Hot-Plugging

People: Rusty RussellChristoph HellwigAlexander Viro

Rusty Russell posted a link and announced, "Version 0.3 (untested) of the HotPlug CPU Patch is out, with ia64 and x86 support." Bringing a CPU up and down, he said, was as simple as changing the value of /proc/sys/cpu/1. Christoph Hellwig suggested using /proc/sys/cpu/<num>/enable instead, so that "other per-cpu sysctls could be added more easily." Rusty agreed it would be better, but said, "rewrite the sysctl crap first to make dynamically adding and deleting entries sane." Alexander Viro chimed in, "I had, actually. 2.5 stuff, but as soon as fs/super.c merge gets into the sane area I'll see what can be safely merged into 2.4. Sorry - it touches quite a few places and running two splitups in parallel... <shudder> As soon as this fscking roll of barbwire^W^W^Wset of locking changes gets untangled..."

10. Linux Human Interest Story (Tear Jerker)

16 Jun 2001 - 18 Jun 2001 (9 posts) Subject: "Kernel configuration. It's not just a job, it's an adventure!"

Topics: BSD, Disks: IDE, Disks: SCSI, Hot-Plugging, I2O, Kernel Build System, PCI, SMP, USB

People: Eric S. RaymondWayne BrowneWayne Brown

Eric S. Raymond finally snapped, and said (as they wheeled him down to his padded cell):

Various people on the Linux kernel mailing list and elsewhere have been heard to opine that CML2's user interface is too oriented towards nontechnical users. In response to these complaints, I have implemented a fourth CML2 front end with an interface style expressly designed for the serious, hard-core hacker. A transcript of an example session follows:

Welcome to CML2 Adventure, version 1.6.1.
You are in a maze of twisty little Linux kernel options menus, all different.
The main room. A sign reads `Linux Kernel Configuration System'.
Passages lead off in all directions.

> n
The arch room. A sign reads `Processor type'.
A passage leads upwards.

Choose your processor architecture.
A brass lantern is here.
There is a row of buttons on the wall of this room. They read:
The button marked X86 is pressed.
> take lantern
Lantern: taken.
> look X86
Value of X86 is y.
This is Linux's home port. Linux was originally native to the Intel 386, and runs on all the later x86 processors including the Intel 486, 586, Pentiums, and various instruction-set-compatible chips by AMD, Cyrix, and others.
> up
In main room.
> nearby
The arch room. A sign reads `Processor type'.
The archihacks room. A sign reads `Architecture-specific hardware hacks'.
The buses room. A sign reads `System buses and controller types'.
The pm room. A sign reads `Power management'.
The mtd room. A sign reads `Memory Technology Device (MTD) support'.
The x86 room. A sign reads `Intel and compatible 80x86 processor options'.
The policy room. A sign reads `Configuration policy options'.
The generic room. A sign reads `Architecture-independent feature selections'.
The block_devices room. A sign reads `Block devices'.

> go generic
The generic room. A sign reads `Architecture-independent feature selections'.
A passage leads upwards.

There is an option named MODULES here.
There is an option named NET here.
There is an option named SYSVIPC here.
There is an option named BSD_PROCESS_ACCT here.
There is an option named SYSCTL here.
There is an option named BINFMT_AOUT here.
There is an option named BINFMT_MISC here.
There is an option named SMP here.
> take NET
NET: taken.
> take MODULES
Tristate symbols won't default to M.
MODULES: taken.
> up
In main room.
> nearby
The arch room. A sign reads `Processor type'.
The archihacks room. A sign reads `Architecture-specific hardware hacks'.
The buses room. A sign reads `System buses and controller types'.
The pm room. A sign reads `Power management'.
The mtd room. A sign reads `Memory Technology Device (MTD) support'.
The x86 room. A sign reads `Intel and compatible 80x86 processor options'.
The policy room. A sign reads `Configuration policy options'.
The generic room. A sign reads `Architecture-independent feature selections'.
The block_devices room. A sign reads `Block devices'.

> go buses
The buses room. A sign reads `System buses and controller types'.
A passage leads upwards.

Specify the buses, disk controllers, and internal interconnection standards that you want your kernel to support.
It is very dark. If you continue, you are likely to be eaten by a grue.
There is an option named EISA here.
There is an option named PCI here.
There is an option named PNP here.
There is an option named PARPORT here.
There is an option named HOTPLUG here.
There is an option named IDE here.
There is an option named SCSI here.
There is an option named USB here.
There is an option named I2O here.
There is an option named MTD here.
There is an option named WATCHDOG here.
> light lantern
The lantern radiates a mellow golden light.
> take PCI
PCI: taken.
> help
Welcome to the adventure configurator. For a command summary, type `commands'.
In general, a three-letter abbreviation of any command word is sufficient to identify it to the parser.

This interface emulates the style of classic text adventure games such as Colossal Cave Adventure and Zork. Configuration menus are rooms, and configuration options are objects that can be taken and dropped (except for choice/radiobutton symbols, which become buttons on various room walls). Objects and rooms may silently appear and disappear as visibilities change.

Have fun, and beware of the grues!

In main room.

> commands
look [target] -- look here or at target (direction or option).
nearby -- list nearby rooms (useful with go)
go -- go to a named menu (follow with the label).
inventory -- show which options you have picked up.
drop -- unset option.
take [module] -- set option, follow with option name.
press -- press a button (follow with the button name).
set -- set numeric or string; follow with symbol and value.
load -- read in a configuration (follow with the filename).
save -- save the configuration (follow with a filename).
xyzzy -- toggle suppression flag.
quit -- quit, discarding changes.
exit -- exit, saving the configuration.

You can move in compass directions n,e,w,s,ne,nw,se,sw or dn for down.

> quit

Several folks felt that Eric needed help immediately if not sooner, and Eric later confessed, "I wrote most of CML2 Adventure on a long airplane flight." But Wayne Browne said, "OK, Eric, you've finally done it. You've bypassed my objections to CML2 and won me over. I *have* to try it now. :-)" Eric chose to blame an imaginary being named "Rick Moen" (clearly an invented cognate of his own name, to whit: "Eric" -> "Rick", and "RayMond -> "Moen" -- a typical childish transposition in this sort of case).

One of the doctors made the mistake of suggesting that Eric might not have actually written the code to do this, and that the log file was merely the fabrication of a fevered mind. But Eric said, "CML2 Adventure is part of the 1.6.1 release of CML2. You can download it from and try it out yourself."

Thus endeth the thread.

11. Hackers Dropping Like Flies

20 Jun 2001 (5 posts) Subject: "is there a linux running on jvm arch ?"

Topics: User-Mode Linux

People: David FortBruce HolzrichterJeff DikeEric S. Raymond

Eric S. Raymond was not the only unfortunate victim this week. David Fort suggested from atop his Frankensteinian lair, "I've tested the User Mode Linux a few times ago, and it gave me an idea: given the fact that we had a GCC which produce bytecode from C, it would be possible to produce a port of linux(a new directory "jvm" in the arch dir) which would run in a Java Virtual Machine. (after some inquiries such compiler does not exist :-( ) I'm dreaming of a linux booting in a browser applet(imagine sending such thing in a mail to MS peoples !!!!)" Bruce Holzrichter replied, "While I am not sure if this is possible with Linux, something like this has already been done with Inferno. Check out:" . And Jeff Dike added:

If you really want to help the MS peoples get Linux, consider a straight port of UML to Windows.

I've been trying to encourage someone to do this for a while, with limited success :-( Enough has been done that I think I know what the main obstacles are, and I think I know that it's possible.

So, if you're interested (and have the appropriate Win-fu) let me know, and grab the code and start porting...







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.