Thanks Crossfire for the valuable information. Tharanga
On Sat, Apr 24, 2010 at 12:00 PM, <[email protected]> wrote: > Send coders mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.slug.org.au/listinfo/coders > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of coders digest..." > > > Today's Topics: > > 1. Re: New to Kernel programming and device drivers (Crossfire) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 24 Apr 2010 11:31:02 +1000 > From: Crossfire <[email protected]> > Subject: Re: [coders] New to Kernel programming and device drivers > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 21/04/2010 11:14 AM, Tharanga Abeyseela wrote: >> Thanks Nick. I thought to write a characther driver or a block driver >> first, then i can move to another level. how about Linux device >> drivers , understanding the linux kernel book (Orielly), and wrox >> professional Linux kernel architecture ? iam looking for a book which >> suits for learner..(step by step guide kind of a document, which >> explains from the beginning). i wanna right it my own..iam doing this >> as a pet project. > > That's all nice and fine, but you really do need to have a goal when > trying to do this sort of stuff, and most of the easy targets have > already been dealt with. > > Likewise, assess if what you want to achieve can be in in userspace > first - coding in userspace is far easier to do, far easier to debug, > and teaches you a lot about what it is you're trying to achieve in the > first place without the associated headaches of trying to develop for a > moving target. Also, if it can be done in userspace, then it probably > should be - putting more code in the kernel is something we should be > avoiding. > > Find yourself something to write a driver for. Learn how the > interconnect your peripheral uses works. (For example, You can't write > a driver for a USB device if you don't understand the basics of how USB > works). Start researching what you need to achieve in the kernel to make > it work by reading through the source of drivers for similar deviecs, > and trying to match them against any known specifications. If you don't > have specifications for the device you're trying to add support for, > spend a helluva lot of time trying to capture behaviour or disassemble > existing drivers (if permitted via license). Once you've got a pretty > good idea of how the bits fit together, go forth and actually write your > driver and be prepared to crash your machine a lot. :) > > The books can be useful, but they date very very quickly - being able to > read through the kernel source and understand what's happening is far > more useful. > > C. > > > ------------------------------ > > _______________________________________________ > coders mailing list > [email protected] > http://lists.slug.org.au/listinfo/coders > > > End of coders Digest, Vol 45, Issue 3 > ************************************* > _______________________________________________ coders mailing list [email protected] http://lists.slug.org.au/listinfo/coders
