Kernel Traffic #95 For 27 Nov 2000

Many, many thanks go to Björn Eriksson for pointing out a serious bug in the People Indices, where not all occurrences of a given name were being found in a given issue section. This should make a big difference throughout a lot of back issues as well. Thanks, Björn!

There were 322 different contributors. 157 posted more than once. 139 posted last week too.

David Woodhouse posted a patch to fix some PCMCIA stuff, and added, "If the fact that i82365 and tcic are broken in 2.4 isn't on Ted's critical list, then I think it probably ought to have been - and this should fix it." But Jeff Garzik replied, "It's purposefully not on Ted's critical list, the official line is "use pcmcia_cs external package" if you need i82365 or tcic instead of yenta AFAIK." Pavel Machek was a bit dismayed by this, and asked for confirmation from Theodore Y. Ts'o. Ted in turn replied:

It was Linus who said that Pcmcia crashing wasn't necessarily a critical bug since 2.2 didn't have Pcmcia support in-kernel, and that for 2.4, it was likely that most distributions would be best served to ship with David Hind's external pcmcia driver.

That was several months ago, and perhaps things have changed. But that was I didn't spend time worrying about tracking PCMCIA bug reports; there were a non-trivial number of them, and they were mostly of the form "doesn't work on XXX hardware", "causes kernel oops on YYYY hardware", etc.

David Hinds brought folks uptodate with, "Some of these have been resolved, but some remain. They have not been easy things to decipher since they involve interactions between the PCI subsystem, PCMCIA, and specific hardware." Alan Cox also replied to Ted, saying, "From a practical point of view that currently means 'delete Linus tree pcmcia regardless of what you are doing' since the modules from David Hinds and Linus pcmcia are not 100% binary compatible for all cases. It isnt possible for anyone to ship a useful system with Linus pcmcia unless the ISA stuff is fixed." Russell King pointed out that deleting PCMCIA from the tree would leave ARM machines with no PCMCIA support, but Alan replied, "It would actually have made no difference as said code didnt actually work anyway." A couple posts later, Russell clarified:

I was referring to the embedded-type ARM devices of which I have two sat in front of me (both are manufactured within the past year so are "current") and about half the platforms that "ARM Linux" covers have some form of PCMCIA.

Some ARM CPUs even have the PCMCIA controller embedded within them (look at arch/arm/tools/mach-types - each entry containing a reference to SA1100 means that particular platform has the ability to use PCMCIA).

All of the drivers for these devices were written around the in-kernel PCMCIA code.

Linus Torvalds got into the act and there were some patch exchanges, but nothing explicitly came out regarding whether the patches would be taken into the main tree.

Dax Kelson reported, "I just got a Sceptre 6950 (also known as a Dell 5000e), I just installed Red Hat 7.0 on it, and got an APM related oops at boot." He also noticed that this problem had been reported before, though no solution had been found. Brad Douglas replied, "We have an open ticket with Compal (the manufacturer) about the problem. The 32-bit Get Power Status (0AH) call is broken." But Alan Cox added in response to Dax, "This is not a Linux problem" [...] "There are no fixes. Return the faulty equipment to the vendor and suggest they get a QA department." Dax replied, "Supposedly there will be a BIOS update in the "future" to correct this problem," and suggested that the kernel try to work around this problem, as it did with other hardware problems, since a lot of folks were expected to buy that laptop. Alan rejoined, "And I hope many many of these people demand BIOS upgrades or send them back." John D. Kim replied, "most of them will be running Windows, and Windows seem to work fine with it. So these companies aren't going to see too many requests unless anyone who's even considering buying a new laptop complain about this. Compal provides no communication channel for the consumers, so we have to go through the big companies like dell. When I e-mailed dell's tech support I got a response from a guy who had *no* idea what linux is." Pavel Machek replied shortly, "Disable apm and be done with that! I do not see why this is a problem. Just add comment to apm.c, there are more comments about b0rken machines in there."

Stephen Gutknecht had some problems building the kernel, and posted a link to the steps he took to do the compile. After looking this over, Keith Owens replied, "Hand editing the .config file gives undefined results. Make all changes through menuconfig or xconfig. The config system does lots of work behind the scenes which is not peformed if you hand edit." Jeff Garzik replied, "Hand editing works just fine... You just have to remember to run "make oldconfig" afterwards." But Richard B. Johnson corrected, "Only __sometimes__. There are "questions" that will be skipped even in `make oldconfig` if some things are hand edited. Hand editing, followed by `make oldconfig` works only if you know what you are doing." End Of Thread (tm).

Matthew Carlisle asked if there were any plans to support a sound driver for the Cyrix/NatSemi CS5530 chipset. Alan Cox replied, "None whatsoever. Use the sb16 driver." But Chng Tiak-Jung added, "Go register as a developer on National Semiconductor's website and you can download the source to the native audio support for CS5530. However, my understanding is that this driver will only work on system with BIOS that support VSA2, so you may need to upgrade your BIOS first."

Andreas S. Kerber asked if it was possible to handle 10G files under Linux, and Andreas Jaeger gave a pointer to the Large File Support In Linux page and replied, "Yes, with recent 2.4 kernels or a patched 2.2 kernel - and a recompiled glibc."

I'd like to put the following document into the kernel tree as linux/Documentation/SubmittingPatches, and would like to get comments on it.

I've likely left out a lot in Section 2... additions welcome. I don't want to get too domain-specific in section 2, but I would like to cover as many "unwritten general rules" as possible.

How to Get Your Change Into the Linux Kernel
or
The Unofficial Linus HOWTO

For a person or company who wishes to submit a change to the Linux kernel, the process can sometimes be daunting if you're not familiar with "the system." This text is a collection of suggestions which can greatly increase the chances of your change being accepted.

SECTION 1 - CREATING AND SENDING YOUR CHANGE

"diff -u"

Use "diff -u" or "diff -urN" to create patches.

All changes to the Linux kernel occur in the form of patches, as generated by diff(1). When creating your patch, make sure to create it in "unified diff" format, as supplied by the '-u' argument to diff(1). Patches should be based in the root kernel source directory, not in any lower subdirectory.

To create a patch for a single file, it is often sufficient to do:

SRCTREE=/usr/src/linux
MYFILE=drivers/net/mydriver.c

cd $SRCTREE
cp $MYFILE $MYFILE.orig
vi $MYFILE # make your change
diff -u $MYFILE.orig $MYFILE > /tmp/patch

To create a patch for multiple files, you should unpack a "vanilla", or unmodified kernel source tree, and generate a diff against your own source tree. For example:

MYSRC=/devel/linux-2.4

tar xvfz linux-2.4.0-test11.tar.gz
mv linux linux-vanilla
diff -urN linux-vanilla $MYSRC > /tmp/patch
Describe your changes.

Describe the technical detail of the change(s) your patch includes.

Be as specific as possible. The WORST descriptions possible include things like "update driver X", "bug fix for driver X", or "this patch includes updates for subsystem X. Please apply."

If your description starts to get long, that's a sign that you probably need to split up your patch. See #3, next.
Separate your changes.

Separate each logical change into its own patch.

For example, if your changes include both bug fixes and performance enhancements for a single driver, separate those changes into two or more patches. If your changes include an API update, and a new driver which uses that new API, separate those into two patches.

On the other hand, if you make a single change to numerous files, group those changes into a single patch. Thus a single logical change is contained within a single patch.

If one patch depends on another patch in order for a change to be complete, that is OK. Simply note "this patch depends on patch X" in your patch description.
Select e-mail destination.

The arbiter of all Linux kernel changes is Linus Torvalds. His e-mail address is torvalds@transmeta.com.

He gets a lot of e-mail. I mean a LOT. So you want to do your best to avoid sending him e-mail. :)

Before sending your change to Linus, look through the MAINTAINERS file and the source code, and determine if your change applies to a specific subsystem of the kernel, with an assigned maintainer. If so, e-mail that person instead.

If no maintainer is listed, or the maintainer does not respond, send your patch to the primary Linux kernel developer's mailing list, linux-kernel@vger.kernel.org, in addition to Linus. Most kernel developers monitor this e-mail list, and can comment on your changes.
Select your CC (e-mail carbon copy) list.

Other kernel developers besides Linus need to be aware of your change, so they want comment on it and offer code review and suggestions.

When e-mailing your change, typically the change is copied to the primary Linux kernel developer's mailing list, linux-kernel@vger.kernel.org. Other mailing lists are available for specific subsystems, such as USB, framebuffer devices, the VFS, the SCSI subsystem, etc.

Even if the maintainer did not respond in step #4, make sure to ALWAYS copy the maintainer when you change their code.

If your change is in any way large (conceptually, not byte size) or controversial, you should copy linux-kernel@vger.kernel.org, so that the change can be discussed.
No MIME, no links, no compression, no attachments. Just plain text.

Linus and other kernel developers need to be able to read and comment on the changes you are submitting. It is important for a kernel developer to be able to "quote" your changes, using standard e-mail tools, so that they may comment on specific portions of your code.

For this reason, all patches should be submitting e-mail "inline".

Do not attach the patch as a MIME attachment, compressed or not. Many popular e-mail applications will not always transmit a MIME attachment as plain text, making it impossible to comment on your code. A MIME attachment also takes Linus a bit more time to process, decreasing the likelihood of your MIME-attached change being accepted.
E-mail size.

When sending patches to Linus, always follow step #6.

Large changes are not appropriate for mailing lists, and some maintainers. If your patch, uncompressed, exceeds 40Kb in size, it is preferred that you store your patch on an Internet-accessible server, and provide instead a URL (link) pointing to your patch.
Name your kernel version.

It is important to note, either in the subject line or in the patch description, the kernel version to which this patch applies.
Don't get discouraged. Re-submit.

After you have submitted your change, be patient and wait. If Linus likes your change and applies it, it will appear in the next version of the kernel that he releases.

However, if your change doesn't appear in the next version of the kernel, there could be any number of reasons. It's YOUR job to narrow down those reasons, correct what was wrong, and submit your updated change.

It is quite common for Linus to "drop" your patch without comment. That's the nature of the system. If he drops your patch, it could be due to
- A style issue (see section 2),
- An e-mail formatting issue (re-read this section)
- A technical problem with your change
- He gets tons of e-mail, and yours got lost in the shuffle
- You are being annoying (See Figure 1)
When in doubt,

SECTION 2 - HINTS, TIPS, AND TRICKS

This section lists many of the common "rules" associated with code submitted to the kernel. There are always exceptions... but you must have a really good reason for doing so. You could probably call this section Linus Computer Science 101.

Read Documentation/CodingStyle

Nuff said. If your code deviates too much from this, it is likely to be rejected without further review, and without comment.
#ifdefs are ugly

Code cluttered with ifdefs is difficult to read and maintain. Don't do it. Instead, put your ifdefs in a header, and conditionally define 'static inline' functions, or macros, which are used in the code. Let the compiler optimize away the "no-op" case.

Simple example, of poor code:

dev = init_etherdev (NULL, 0);
if (!dev)
return -ENODEV;
#ifdef CONFIG_NET_FUNKINESS
init_funky_net(dev);
#endif

Cleaned-up example:

(in header)

#ifndef CONFIG_NET_FUNKINESS
static inline void init_funky_net (struct net_device *d) {}
#endif

(in the code itself)

dev = init_etherdev (NULL, 0);
if (!dev)
return -ENODEV;
init_funky_net(dev);
'static inline' is better than a macro

Static inline functions are greatly preferred over macros. They provide type safety, have no length limitations, no formatting limitations, and under gcc they are as cheap as macros.

Macros should only be used for cases where a static inline is clearly suboptimal [there a few, isolated cases of this in fast paths], or where it is impossible to use a static inline function [such as string-izing].

'static inline' is preferred over 'static __inline__', 'extern inline', and 'extern __inline__'.
Don't over-design.

Don't try to anticipate nebulous future cases which may or may not be useful: "Make it as simple as you can, and no simpler"

There was general approval of this list, and some discussion of improvement. Peter Samuelson pointed out, "For nontrivial changes you should basically never send them straight to Linus (unless you yourself are a maintainer) -- first offer them up on mailing lists and get feedback. Tell people to look in MAINTAINERS for the appropriate list, with possible CC to linux-kernel." But he added, "for simple typo corrections and such, Linus should probably get a CC even if you are mailing another maintainer. I.e. one less level of indirection for the trivial stuff."

He also added a tenth item, "Make sure your patch is up to date, and keep it that way. Until it is accepted into the main tree, you need to make sure it always applies without errors to the most recent kernels, including pre-patches. (Line offsets are OK; the 'patch' command has no trouble with these.) This can be a lot of work when the kernel is in a volatile state, but it is good if you can make sure that you are no more than 2 or 3 days behind "the latest". Note that if you followed 3) and your patch is small and self-contained, in many cases you won't need to change it for weeks."

And an eleventh, "If Linus or others tell you a change is stupid, chances are they have a point. If you must argue your case, use technical reasoning, not marketing. Arguments like "but XXX OS does it this way" carry very little weight -- instead, give us independent reasons why "this way" is good. Linux is not Solaris, NT, FreeBSD, or BeOS, and we like it that way. Arguments like "but XXX is required for better YYY compliance" carry more weight, but you may still need to justify why YYY compliance is important, and why it can't be achieved another way. Arguments like "but we have BIGNUM customers / software vendors / gov't agencies who will deploy/support Linux as soon as it has feature XXX" are completely worthless, unless you can show that those customers, vendors or agencies have solid technical reasons to want feature XXX (as opposed to "but XXX OS does it this way and we don't want to port our software" reasons)."

Elsewhere, Alan Cox suggested the title, "Care And Operation Of Your Linus Torvalds". He also felt Jeff should include a reminder that "If your mailer is mangling patches then someone may ask you to resend them using MIME." He also said, somewhat cryptically for those not already in the know, "Include Tigrans recommended exclude list and info." Tigran Aivazian replied:

Alan Cox is very concise. I shall interpret :) He refers to the dontdiff file I currently maintain on: http://www.moses.uklinux.net/patches/dontdiff and the command line to make the patch would become:

diff -urN -X dontdiif linux $MYSRC > /tmp/mysrc.patch

Gary Lawrence Murphy replied that he'd folded this information into the Kernel Wiki on sourceforge.

Someone asked if there were any known issues with using Oracle-8.1.6.1R2 on the latest development kernels. Alan Cox replied, "SHM is resolved but O_SYNC is not yet fixed. You could therefore easily lose your entire database." Jeff V. Merkey replied, "When we ported Oracle to NetWare, we found that making changes to the core file systems in NetWare that Oracle needed would tank FS performance, so we came up with something called direct FS, a separate File System interface just for Oracle." Alan replied, "Its called O_DIRECT and kiovecs. Its already there. Much more generic than an 'oraclefs'."

Someone asked who currently maintained 'vgacon.c', and guessed it might be James Simmons; but James replied, "I do some console work but mostly for 2.5.X. Their is no offical maintainer for this sub system as of now." Jeff Garzik agreed that no one currently maintained it, but added, "James has been hacking around in fbdev for a while and knows his way around video stuff, so he has posted a few patches for vgacon."

Jeff Garzik asked, "What is the difference between a module that exports no symbols and includes EXPORT_NO_SYMBOLS reference, and such a module that lacks EXPORT_NO_SYMBOLS? Alan once upbraided me for assuming they were the same :)" Keith Owens explained, "When modules were first introduced, all symbols were automatically exported. For kernel 2.0 compatibility, a module without EXPORT_NO_SYMBOLS actually exports everything. There are flags on insmod to override this default. modutils 2.5 will remove this backwards compatibility, no module will export symbols unless they are explicitly exported."

Brian Gerst posted a patch to 'arch/i386/mm/init.c' and Tigran Aivazian replied, "while you were there, so close to paging_init() why not also correct the wrong comment at the top of the function? It talks about 0-4M pagetables whereas we really setup (see head.S) 0-8M." Brian posted a one-liner, and the thread ended.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	13 Nov 2000 - 18 Nov 2000	(46 posts)	Status Of PCMCIA For 2.4
2.	13 Nov 2000 - 18 Nov 2000	(13 posts)	Serious Dell 5000e Laptop Power Management Problems
3.	14 Nov 2000	(4 posts)	Hand Editing '.config' Files
4.	15 Nov 2000	(3 posts)	NatSemi CS5530 Sound Support
5.	15 Nov 2000 - 16 Nov 2000	(4 posts)	Large File Support
6.	16 Nov 2000 - 18 Nov 2000	(10 posts)	Guide To Submitting Patches
7.	17 Nov 2000 - 18 Nov 2000	(9 posts)	Using Oracle On Latest Development Kernels
8.	17 Nov 2000	(3 posts)	Status of 'vgacon'
9.	17 Nov 2000 - 19 Nov 2000	(8 posts)	Some Explanation Of Modules Exporting Symbols
10.	18 Nov 2000	(3 posts)	Some Developer Interaction

Kernel Traffic #95 For 27 Nov 2000

By Zack Brown