Messages in this thread | | | Date | Sun, 13 Jun 2010 13:03:50 -0400 | Subject | Re: Help for a newbie | From | Someone Something <> |
| |
Thanks for the very thorough reply. As for the syscalls, I just wanted to add one that gave you the task descriptor struct for the init process, just for fun. I would also like to start writing kernel modules. I'm not exactly experienced with hardware so I'll probably put off device drivers for a while.
Thanks a lot,
Dhaivat
On Sun, Jun 13, 2010 at 9:29 AM, <Valdis.Kletnieks@vt.edu> wrote: > On Sat, 12 Jun 2010 23:32:36 EDT, Someone Something said: > >> 1) when you write userland apps, you usually include stuff like : >> sys/types.h or errono.h where are all these defined in the linux >> kernel because I would like to add a few syscalls of my own? > > Look at any source files already in the kernel, they'll give you a good > hint of where the .h files are. Keep in mind that in the kernel, we > tend to #include a lot of header files, depending on what exactly is needed. > > Regarding adding syscalls - step 0 is doing a proper design and making sure > that in fact you need a new syscall. What features do you want to add, and > why do they need syscalls? > > It's usually a bad idea to add syscalls unless you *really* need to - most > of the time creating a loadable kernel module is a better idea (among other > things, you can compile a module against a distro kernel without rebuilding > the entire kernel, you can't do that with a syscall). > >> 2) what are some bugs in the kernel that a beginner can fix? > > Unfortunately, we're victims of our own sucess here. There really aren't many > long-standing bugs left that a beginner can fix. If you follow the linux-next > or Andrew Morton's -mm kernel, you'll find the occasional typo or messed up > code that has an #ifdef backwards so it doesn't build for all configs, and so > on. But in general, if the bug has been there more than 12 hours or so, it > usually means that it's a nasty ugly mess and will require some real work to > fix. > > That isn't to say that the developers don't appreciate all those little > one-line patches to make stuff work in your config that they didn't test. > They appreciate those a *lot*. I just can't point you at any because the list > will be different by the time you read this mail. > >> 3) is there any definitive guide to the kernel that you guys refer >> most newbies to? (like Programming Perl for perl)? > > Robert Love's book and "Linux Device Drivers, 3rd ed" are both pretty good > overviews, although somewhat dated because the code is a moving target. > Once you got a handle on the major data structures, it's really "Use The > Source, Luke" time. > >> 4) Where's the linux kernel headed to next? What higher level features >> (i.e. real features, not bug fixes) are going to implemented? > > Well, I really can't say anything definite other than "read LKML or at least a > weekly scan of the Subject: lines to see what's new". It's going to be the > same as it has for the last few years - code will be merged when it's written > by somebody who's scratching an itch. We'll eventually merge *something* for > the Android power-management issue (because we really *do* need a solution in > that area), new file systems will be merged, device drivers will be written, > and so on. What will go in for 2.6.36 and later releases pretty much depends on > what code people feel motivated to write for submission. > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |