Well, it's not that hard to find a place to start...
http://lwn.net/Kernel/LDD3

Good luck,
Oliver

The simplest device I can imagine is the serial communications controller - the chip has a very small number of control registers etc. From playing with that you will learn how to access a device's control register via the kernel. Ironically, the bus controllers which ultimately allow you to communicate with the serial controller are much more complex than the serial controller...

Once you have (re)written a 16550 driver you can easily proceed to other drivers. If you want to play with USB, then read up on how to use the USB API. The USB protocol is very complex, so don't even think about (re)implementing that until you have a few years' experience (and a lot of free time to read the protocol specs). The latest Linux USB API in fact makes development so easy that I can't help thinking "am I missing something? creating a driver hasn't been this easy since 1988". USB is a bit different from most 'device drivers' since everything you do is via commands sent by serial line, and that is handled by the API. You do not have to know how to access hardware registers via the kernel to work with USB.

Concentrate on understanding the existing drivers for the class of device you're most interested in - don't attempt to understand all drivers at once - it is simply not possible. For me, aside from learning to set registers and initialize hardware via the kernel, the other important things to learn about drivers in general are:

1. top half / bottom half (kernel space / user space) design - in the end only experience (and testing) will tell you what is not reasonable to stuff into the kernel space processing. In general you must perform only absolute necessary operations and exit the interrupt as soon as possible, but sometimes you really do need to cram a lot into the 'top' half. Learn about the problems involved.

2. handling exceptional circumstances - In the middle of reading or writing data, the user pulls out the USB memory stick. Deal with it. Even in the most current kernels you can often lock up a system by doing such naughty things. In my case I have a D-Link wireless gizmo that uses a Ralink device - I'm happy with the hardware, but when someone pulls out the USB device the computer hangs - it is possible to avoid this problem.

3. handling concurrent requests - Especially now with the 2-core CPUs being pushed onto laptops and desktops, you can bet that you will have issues with multiple overlapping requests from different CPUs. Study how other drivers deal with this. This is a particular problem with storage devices since you need to avoid two processes altering the same storage simultaneously and becoming very confused. In most other cases a protocol layer prevents problems - for example MODBUS (protocol spec) over RS485 (electrical spec) serial comms.

Have fun! After a few months of playing with drivers you should be ready to do some serious work on your favorite gizmo.

Here's a project for you to work on if you REALLY want to get into USB - unfortunately you need access to a device which has both 'client' and 'master' ports: Write a tool to help reverse-engineer a device's protocols. The basic setup is this:
PC -- tool -- USB gizmo
The PC's master port (PC-M) goes to your tool's client port (T-C). The tool logs the information and passes it on to its master port (T-M). The T-M will then receive information from the USB gizmo (U-C). It's a 'man-in-the-middle' reverse engineering tool for USB devices and would prove extremely helpful for developing drivers for ANY USB gizmo which already has a driver for another system. (Of course this scheme is foiled if the device drivers at either end use encryption.)

"If your company is worried about NDA issues surrounding your device's specifications, we have arranged a program with OSDL/TLF's Tech Board to provide the legal framework where a company can interact with a member of the kernel community in order to properly assure that all needed NDA requirements are fulfilled." - Greg KH

I'm not sure what the "legal framework" is, but NDA's can vary wildly; nonetheless the reason for the "pandering" is probably that it's easier than reverse engineering.

For example, previous kernel developers have had NDA's (although that usually meant a binary blob that wouldn't allow kernel inclusion - e.g. pwc drivers for webcams). Obviously if it's getting included into the kernel, there is no binary blob (unless it's firmware).

I don't see the big deal.

Well, this is Linux, not GNU/Linux. Distros are free to strip off any drivers that have been created with NDA's or switch to HURD.

I mean, an NDA is a company's right to its internal documents. The fact that we can have a peek at the specs is a blessing, and if we can't share it with others (who would mostly not be interested in it anyway) it's OK. The most important thing is getting the drivers to work.

Face it: Linux isn't about Free Software. Linux is about Open Source.

NDA's are a very broad group, maby he just means that kernel hacekers will not tell the public untill after the device hits the market.

In order to convince people to give us documentation so that we can get our hardware working. All ways are good as long as we get our hands on the stuff that we need.

This is also a great media stunt, it creates goodwill that the community later on can cash in on to push it's own agenda on other areas.

Why is signing a non-disclosure agreement unethical?
The way I look at it, some agreements are, and some aren't. Read the fine print.

Why are industry executives "pinheads?" They may have a different set of concerns than kernel developers, but that doesn't mean they're stupid.

Another good idea would be for some of the hackers to found hardware companies that create fully Free (in the sense of the soft/firmware that runs them) hardware devices.

Another good idea would be for you and RMS to build a magical hot air balloon and fly to Mars, establishing a Free Commune where the concept of money was obsolete.

Meanwhile, we engineers (not politicians) will be working on code and hopefully benefiting the community.

This is not a matter of making the companies happy. This is an effort to integrate as many devices that are compatible in Windows into Linux distributions, to make Linux a more realistic approach for a larger percentage of Linux consumers.

Someone who has decided to give Linux a try, who has been on Windows for years, that can't get their printer working because a Linux driver hasn't been developed yet is going to be turned off by the thought of A) buying a new printer, or B) not having a printer.

The truth is, these drivers will probably be produced by the Linux Development community eventually anyway - this is just a means to expedite the process.

Hi, it seems you're trying to write a troll and/or flamebait. Would you like some assistance with that?

A language correction: "sounds kind of trollish too me." should be "sounds kind of trollish to me." Note the single 'o'.

"But what should one expect from a guy, who just..." bla bla, is commonly known as an ad hominem attack, and is very often used by inexperienced trolls. You should be able to do better than that.

Or, in other words, f*ck off, lamer. You're just boring. (Note how I cleverly allowed myself to sink to your own level. Neat, huh?)

Except they don't allow NDA's.

What does it have to do anything with how various companies act?
Have you read the announcement of Greg?

If so, look at the date. Then tell me if you know BEFORE that
date that he will write such an email. =)

I am unhappy that people do not support Greg KH.

If you think about it for some time, this is one
of the best ideas in the most recent years for Linux
as a whole.

They offer you to maintain the drivers for your
hardware and they also wont let NDAs potentially
stop them. What is bad about this?

Linux Kernel will always remain GPL, thus open
source. If a distribution wants to remain "pure",
simply strip these devices you feel are
"tainted". The others can use them if THEY want.

The problem with Microsoft's specs is not lack of them. Microsoft specifications do not include everything.

These little Microsoft's bugs make a big difference.

Who are you kidding?

This documentation was written by Linux NTFS driver developers. There already is a Linux file system implementation adhering to this documentation.

Quoting this documentation file:

This is technical documentation, created to help the programmer.It was originally written to complement the Linux NTFS driver.

Microsoft hasn't released any documentation for NTFS. These documents have been pieced together partly by carefully reading all the SDKs and Windows help but mostly by reverse-engineering the filesystem.