• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Linux kernel documentation?

Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
Originally posted by: n0cmonkey
Originally posted by: Hyperblaze

that could very well be. They either attracted a technical writer to their group or one of them actually likes technical writing lol.

Or more likely they hate it as much as everyone else, but realize how important good documentation is to a project.

i stand corrected. third option added 😀
 
Originally posted by: Hyperblaze
Originally posted by: n0cmonkey
Originally posted by: Hyperblaze
Originally posted by: n0cmonkey
Originally posted by: Hyperblaze
Originally posted by: n0cmonkey
linux-2.6.11.4/drivers/net/wireless might have what I'm looking for, as soon as I decipher the information...


/usr/src/linux/Documentation/networking$ ?

No, I didn't see what I'm looking for in there. I could be mistaken, but my searches didn't turn up anything.


you mentioned wireless in your above post

so all i did was

grep -ri 'wireless' *
and that directory turned up

I did the same thing, but the information I am looking for did not pop up. 🙂


in all fairness, the information you originally supplied was rather vague 😉

i thought at first you were actually looking for motherboard chipset.

then video card chipset. then discovered it was wireless.

I know, the hunt is more fun when you don't know what you're hunting. 😕
 
I don't know of any master list of supported chipsets, generally I just grep through the files in source-tree/drivers/<type of card>.
 
Originally posted by: Nothinman
I don't know of any master list of supported chipsets, generally I just grep through the files in source-tree/drivers/<type of card>.

That's what I eventually ended up doing, but don't you think it's a bit ridiculous?
 
Probably. But to be accurate there would have to be several different sources anyway since available drivers can differ between distributions depending on which patches they apply. I have to do it so rarely it doesn't really bother me.
 
Originally posted by: Nothinman
Probably. But to be accurate there would have to be several different sources anyway since available drivers can differ between distributions depending on which patches they apply. I have to do it so rarely it doesn't really bother me.

There's a simple solution for that: kernel developers (vanilla kernel) update their list of working hardware. Distributions update their list further with the information from their third party patches. Ta-da! 😛
 
Originally posted by: n0cmonkey
Originally posted by: Nothinman
Probably. But to be accurate there would have to be several different sources anyway since available drivers can differ between distributions depending on which patches they apply. I have to do it so rarely it doesn't really bother me.

There's a simple solution for that: kernel developers (vanilla kernel) update their list of working hardware. Distributions update their list further with the information from their third party patches. Ta-da! 😛

that's an awful lot of work....would you not rather have better support for hardware then a decent documentation format? 😉
 
There's a simple solution for that: kernel developers (vanilla kernel) update their list of working hardware. Distributions update their list further with the information from their third party patches. Ta-da!

Did you just volunteer? =)
 
Originally posted by: Hyperblaze
Originally posted by: n0cmonkey
Originally posted by: Nothinman
Probably. But to be accurate there would have to be several different sources anyway since available drivers can differ between distributions depending on which patches they apply. I have to do it so rarely it doesn't really bother me.

There's a simple solution for that: kernel developers (vanilla kernel) update their list of working hardware. Distributions update their list further with the information from their third party patches. Ta-da! 😛

that's an awful lot of work....would you not rather have better support for hardware then a decent documentation format? 😉

Um, it's 2 minutes worth of work.

New chipset supported.
vi hardware_list.txt
shift G, $, a, CR, blah blah blah, :wq
Start working on next chipset.
 
Originally posted by: Nothinman
There's a simple solution for that: kernel developers (vanilla kernel) update their list of working hardware. Distributions update their list further with the information from their third party patches. Ta-da!

Did you just volunteer? =)

d'oh!

I kept the list of stuff I found. I don't understand what some of those files are for though.

And don't you think a real linux user should do that kind of stuff? 😛
 
Originally posted by: n0cmonkey
Originally posted by: Nothinman
Um, it's 2 minutes worth of work.

I think he meant the initial list compilation.

Oh, yes, that. If they had kept up with it in the first place... 😛

I believe that they haven't felt the needs thanks to all the different mailing lists and open source forums which already provide help in that regard.

Besides..they probably thought "who the heck wants to read pages and pages of documentation, it will just put them to sleep"
 
Originally posted by: Hyperblaze

I believe that they haven't felt the needs thanks to all the different mailing lists and open source forums which already provide help in that regard.

That's just a duplication of work.
Good ducmentation: Write once, reference many.
Poor or no documentation: Write many.

Besides..they probably thought "who the heck wants to read pages and pages of documentation, it will just put them to sleep"

No, like any other *nix, you'll see your share of RTFMs on their mailing lists too. 😉
 
Back
Top