Date: Wed, 29 Jan 1997 22:01:40 -0500 From: "Brian J. McGovern" <mcgovern@spoon.beta.com> To: msmith@atrad.adelaide.edu.au Cc: hackers@freebsd.org Subject: Cases (was: Constructive Criticism) Message-ID: <199701300301.WAA09208@spoon.beta.com>
next in thread | raw e-mail | index | archive | help
>> I've been noticing, more an more, that FreeBSD has been/is being >> divided in to two camps. Basically, the "has", and the "has >> not". What I mean by this, is that there appears to be the core >> team, who kick butt making this stuff all work, then the people like >> me, who'd like to help out where they can, but seem to have an >> incredible time getting started. > >This is called the "learning curve". There are two ways to climb it, for >climb it you must if you want to do anything. > >1) Spend lots of time trying, asking questions, exercising your intelligence > and patience. >2) Give lots of money to someone else to have them force you through 1). I disagree with your two cases. As with any development decision, if I can't justify the cost of undertaking the certain project, I won't even begin it. In the case of #1, its a time/learning curve that is out of reach. By the time I figure it out for release x.y.z, its usually changed. Even so, digesting x amount of data in reasonable size time chunks (I usually get 20 minutes a couple of time a day here or there to work on these types of projects, maybe totalling an hour or so a day). In your second case, the dollar cost would also be out of reach. > >The "have/have not" stance, in this case, is sour grapes because you >haven't made it up yet. There isn't some cabal trying to keep you >ignorant and frustrated - developers are desperately desired! > >Case 2) really only manifests when there are lots of people desperate >to climb and stupid enough to part with the sort of money involved, >which isn't the case with FreeBSD. > >> you can't beam armies up to your ship, but I digress... I'd like to >> submit it in to the "games" section of the ports. However, I notice >> this great little file structure that allows you to type "make >> install clean", and bam! the application is made, installed, and the >> working space is cleaned up. > >It's in the handbook, in the section on ports. It looks like a cookbook >to me. Or perhaps you could look at a few other ones that might be >similar to yours - learn by example? Ok, so one bad example ;p But, still, I've noted a good chunk of the technical docs in the handbook always seems to be a release out of date. Again, perhaps its something that can be undertaken. > >> The second major area of concern in my eyes is device >> drivers. Someone pointed me to a section of handbook that dealt with >> doing it (supposedly), but it was terribly out of date. Back to > >If you can't work out how device drivers are integrated, I seriously >doubt that you're up to writing one in the first place. 8( > Ah, again, a circle effect. You'll never get good till you've chewed on a handful of them. And you'll never start on your first till you think you can do it. A lack of documentation makes it infinately more difficult. Again, being under time limitations to "play" with this type of material in _ORDER_ to get good at it, it will take some spoon feeding. But, like my original message said, if I _am_ able to learn something useful, and return an equal amount, or more time on development than what you took to teach me, its a win all around. >However, I'll note that I've been helping people learning DD writing for >a while now (not that I'm any expert at it either), and I've never >seen your name attached to a question going past. How are you supposed >to learn if you never _ask_? > Thats easy. Its something I have a passing interest in undertaking. Unfortunately, my time to tinker with such things is limited. I've banged out some test code in the past (simple device reads, writes, etc), but don't have a weekend to figure out how to stick it in the kernel. And until I know I have a weekend to make a concerted effort, I won't bother anyone with the newbie question. Why ask the question if the answer would be useless? When the time comes, I'll ask. However, I'd also like to keep the number of questions I have to ask to a bare minimum. I'd rather have it be "I'm doing XYZPDQ, and it blows up in such and such a way. Can any one see any obvious problem", than "What do I do now?". It needs to be something I can digest in 20 minute chunks of time, over a long period of time. >> I guess what I'm getting at is this: There are a lot of us out here >> who would write man pages if we knew how to typeset them, those who >> would write neat utilities if we knew how to poll the information >> from the kernel (hell, I know about zillion people who'd love to >> know how to pull IO/up-down, config statistics from their Ethernet >> interfaces, for instance), those who would write drivers for widget >> X if they knew how to get them in to the kernel (there are a million >> books on writing drivers, but none that I know of that speak >> especially about FreeBSD)... > >I hate to say it, but I think that the right line for you is "there >are a lot of us out here that like to whine about doing stuff because >it requires some effort, and we're socialised to expect everything >handed to us on a platter covered with disclaimers". > >_prove_me_wrong_ : I (and plenty of others) are willing to help you >achieve your goals. It's why we're here. 0 I tend to disagree with this sentiment (the silver platter comment) , as well. I agree that a lot of people are like this. But, there are also different levels of interest, and different timeframes. I spend 8 hours plus a day writing code for Cisco. Coming home and spending four hours reviewing device drivers to figure out how to put one together is crazy. However, if there was sufficient documentation on the structures and routines that need to be called to get things set up, I can save the four hours and go straight to putting my effort in to writing the driver. I also realize that some of the kernel routines are being documented in the 3.0 code. I applaud the person (people) doing the work. Also, there are people that learn poorly from example. I'm one of them. That includes everything from programming to learning to fly helicopters (which I now do well, BTW). For me, example goes as far as "Thats neat". For me to grow beyond copying an example in the book, I really need to understand _why_ I'm doing what i'm doing. Reading someone else's chunk of code doesn't tell you WHY they implemented something a certain way... Good commenting would, but if all the code in the world had sufficient commenting, we wouldn't be having this discussion :) But, because I don't like arguing for the sake of arguing, here's a plan. Tomorrow, whilest I'm at work, I will write some code for a pseudo-device driver I wish to call foo. I will write routines for fooinit, fooread, and foowrite. According to the documentation I've read, I should be able to leave the open and close routines set to (I guess NULL ?) nothing. fooinit will also exist, but will just contain a printf to announce the presence of the pseudo-driver. The driver will be a character driver, with major number of 20. Minor number will represent buffer numbers, each buffer will be 1K in length. Writes to a buffer will set the string. Reads will return it (if the full length is specified). Optionally, I'll use the offset attributes to allow multiple reads and writes. Lastly, all of these routines will be in a file called foodev.c. Now, based on my reading, and what I've seen in some of the drivers I _have_ looked at, I believe that I'll have to set a cdevsw structure up, and it looks like a struct isa_driver. I also see probe() and attach() routines that I have not seen documentation on before in the books I have read. I see devfs support thrown in... Looks kinky. Probably will need help there eventually... Anyhow, want to lecture me on what some of these things are, whats required, whats optional, and how my stuff will fit in the cosmic scheme of things? And no, I don't randomly shoot my mouth off about how miserable something is unless I think its worth salvaging, and I'm willing to pitch in _where I can_. If I really just wanted to gripe, I'd keep my mouth shut... Saves on calories. -Brian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701300301.WAA09208>