Re: Learning the FreeBSD Kernel
On Mon, 24 Jan 2000, William A. Maniatty wrote: I'm probably not quite cool enough to be in on the joke here, but what is a dog polisher? You use it to polish your dog. Since all good dog polishers connect to computers running unix, you need a device driver to interface with the dog polisher. You need to be able to tell the dog polisher what size dog is to be loaded, how long the dog is to be polished and you will wish to be notified when the dog is done. :) I'm not making this up. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Parallel port problems... solved! (maybe)
A few weeks ago, I showed up here and was bitching about not being able to send stuff out to my parallel printer. I got a bit of heat for saying that I _could_ send data to the printer from my other system (running Linux). Well, I just wanted to say that all indications now are that the FreeBSD kernel and the FreeBSD parallel port driver have been vindicated. I recently loaded up FreeBSD on that other system and guess what? I can print just fine from that now. Conclusion: It ain't the software. As far as I can tell now, the real problem is/was due to something... I'm not sure exactly what... which is rather non-normal about the on-motherboard parallel port hardware on _this_ specific motherboard, namely, a Tekram model P5V30-B4. But over on my other system that has an ASUS P5A, I got no problems at all printing under either Linux or FreeBSD. I tried to track down the problem with the parallel port hardware on this Tekram P5V30-B4 by throwing a few printfs into the FreeBSD parallel port driver but I didn't get very far... just far enough to see that the parallel port hardware on this (Tekram) board seems to be *really* either broken or else substantially different from what the parallel port driver is expecting. Almost anything the driver did to the on-board parallel port caused that port to come back with the nACK bit set in its status register, and apparently, the driver didn't like that much. :-) I just wanted to set the record straight on this. It was definitely not FreeBSD's fault, as far as I can see now. Has anyone ever used FreeBSD to drive a parallel port on a Tekram p5V30-B4? P.S. Actually, that other (ASUS P5A) system inherited a disk drive that had FreeBSD 3.1 loaded up on it, and that appears to be using the `nlpt' driver, rather than the `lpt' driver that is being used on this (3.3) system on the Tekram. But I don't believe that is relevant. The errors I was seeing seemed to be happening at a lower (ppbus) level. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Better fixit (was: Why was rsh removed from the fixit floppy?)
On Sun, 23 Jan 2000, Kris Kennaway wrote: On Mon, 24 Jan 2000, Peter Jeremy wrote: On Fri, 21 Jan 2000 18:01:34 +0530, Greg Lehey [EMAIL PROTECTED] wrote: If you want a better fixit floppy, you should consider the new custom disk pair with PicoBSD ... There's still space on there; what else could we put there? ssh or OpenSSH (though this might cause distribution problems - how did Jordan's visit to WC's Counsel go?) Unfortunately openssh is quite a bit bigger than the standard ssh, because openssl isn't exactly the slimmest crypto library in the world :-) But, it would definitely be a cool thing. Feel invited to visit freebsd-small, where we discuss now future directions for small floppy-based setups (which include installation disks as well). Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
On Sun, 23 Jan 2000, Warner Losh wrote: : This is what I asked for, when I asked for "other specification". Could : you provide the chapter/verse number of where POSIX spec contradicts the : man pages? It will help me make my case on the TCL forum, since the TCL : developers remain under the mistaken assumption, that select() may : return earlier, but never later than specified. That's trivially easy to show. In theory, but not in practice :-). Given process X with a priority N + 1 that is doing N - 1 (higher priority is actually "lower") while (1) ; while process Y with a priority of N is doing the select. The kernel won't prempt X until the time slice is done, which can be a long time. If the select'd process is swapped out, then it could take a very very long time to swap back in. Um, if the priorities are actually N vs. N - 1, then the process with priority N won't run at the end of the timeslice. It will only run when its priority becomes "lower", possibly several timeslices later. In practice, the priorities will never be N vs. N - 1. The process doing the select() sleeps at priority PSOCK = 24. The process doing the while loop should always have priority = PUSER = 50, but due to a bug (?) in nice(2), the priority of a nice --20 process can be as low as PUSER - 20 = 30. Anyway, that is PSOCK, so the process doing the select() will preempt the user process and wake up as soon as it times out. Then, due to a longstanding scheduling bug (?), the process doing the select() will return to userland without being rescheduled, although its user priority may be much "higher" than that of any other runnable process. Processes that do i/o are thus preferred to cpu hogs much more strongly than their priorities indicate. This bug is a feature in most cases. It reduces context switches. Interactive process may get more benefit from it than from the classical scheduling preference for interactive processes. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Better fixit (was: Why was rsh removed from the fixitfloppy?)
I just want to correct one misunderstanding. 'The Hobbit' is the author of netcat, not l0pht. Ack! I thought he was part of l0pht my apologies for any inaccuracy. I still stand by that either netcat or socket (which I hear does pretty much the same) should be included. /me jumps on -small DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[PATCH] Please test the PS/2 mouse driver patch
I wrote a patch for the psm driver to add support for several PS/2 mice. It is in http://www.freebsd.org/~yokota/ps2mice-24Jan2000.tar.gz. I am attaching README included in the patch. Thank you. Kazu -- PS/2 mouse driver patch for 4.0-CURRENT 24 January 2000 Kazutaka YOKOTA, [EMAIL PROTECTED] This patch adds support for the following PS/2 mice to the psm driver. - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. - MouseSystems SmartScroll Mouse: 3 buttons on top, 1 side button and a wheel. - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. (The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected, but is quietly ignored by the psm driver, as we don't have framework to support it.) There are two diff files: ps2mice.diff moused.diff Apply them to 4.0-CURRENT as follows: cd /sys/isa patch ps2mice.diff cd /usr/src/usr.sbin/moused patch moused.diff Rebuild the kernel and moused. (Note that you need to copy /sys/arch/include/mouse.h to /usr/include/machine/mouse.h before you rebuild moused.) The following is the list of files modified by this patch. /sys/alpha/include/mouse.h /sys/dev/kbd/atkbdcreg.h /sys/i386/include/mouse.h /sys/isa/psm.c /usr/src/usr.sbin/moused/moused.c This patch is for 4.0-CURRENT. Although I personally have not tested yet, I expect you can apply it to 3.4-STABLE without much difficulty. (FYI, /sys/isa/psm.c is for alpha only in 3.4-STABLE. psm.c for i386 is in /sys/i386/isa in 3.4-STABLE.) Kazu -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
-On [2124 10:13], Daniel C. Sobral ([EMAIL PROTECTED]) wrote: Bill Maniatty wrote: First we want to get the mechanism of driver installation down, then try our hands at writing our own driver. I fear that if we roll our own driver software we may find that if we have errors (not that we ever have errors mind you :-) we may not be able to isolate the cause. This is why I was leaning towards reinstalling a working driver first. You won't have any trouble at all with basic driver installation. In fact, this is driver skeleton, that can be templated (and used to... but I don't know if we have newbus templates or not). man 9 driver. Notice that most developers use kld to develop their drivers. Not having to recompile the kernel and reboot really helps. :-) There exists one tutorial-style guide to writing kld's. It's a "hacking" guide to the use of kld's as a way to introduce back-doors in FreeBSD, and though it's somewhat "unclean" wrt to interface description, it's an effective tutorial. I'm sure it can be found from FreeBSD's web site. Trust me, writing modules is the _least_ of your worries. If I can write a module then every^H^H^H^H^Hcluefull people can. =) /usr/src/sys/modules As a next step, I suggest writing "virtual" drivers, not bound to any hardware. There are many such drivers in the tree. As a trivial example, and a favorite of many, the screen savers. The above will get you proficient with the basics of writing device drivers, but still leave a lot out. Let's see... [Not looking at the source code for those I dare say:] But they are not using any busspace/newbus functionality for all I know. And cannot be compared to the `real' drivers IMHO. How mature is the USB driver technology? If it is pretty preliminary we may wish to visit that later. Please recall that we are on a learning curve here. If we support ethernet cards on USB, I'd say it's pretty mature. :-) Anyway, here is what virtual drivers won't teach: how to get resources, which will vary from bus to bus, how to interact with some of the kernel subsystems... How does one write a tun device? How does one write a network device? How does one write a network protocol? How does one write a CAM device (more than one type exist -- some virtual and some not)? How does one write a bus device? When to write a bus (newpcm uses a bus of it's own, if I'm not mistaken)? If you refer to pcm attaching to sbc or gusc. But those are pseudo busses if I understood everything correctly, the same goes for miibus and related busses (ppbus, smbus, iicbus). These problems are mostly distinct from each other, and their usefulness varies. Certainly, a tutorial covering newbus and the main bus types (usb, isa, pci) would be useful and not too difficult to write. CardBus and PCMCIA would be very useful, but we'll have to finish that first :-). Ehm, a tutorial covering the bus types. You have no idea how much you can write about ISA and PCI alone. But it gets complicated from there on. Writing a tutorial on even a subsection of CAM would be very time-consuming. Write a reference so that we can finally convert the last drivers to CAM/newbus. =) Julian had a device skeleton generator way back, I don't know if there is a newbus equivalent or not. I think Peter [Wemm] wrote a skeleton one. Documenting the available debugging tools and useful debugging techniques would be mostly welcome. Aside from "how do I use the kernel debugger", use of tools such as truss, and loading symbol tables to kld's (see Greg Lehey's documentation on debugging vinum) would be useful tutorials. Yeah yeah, coming up. Stop whining. ;) Hey, wait a sec, you said yesterday that you were bored. Nice task for you DCS ;) -- Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/B-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Ain't gonna spend the rest of my Life, quietly fading away... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
On Sun, 23 Jan 2000, Mike Smith wrote: I can't agree with Mike Smith that reading the code is adequate. It certainly doesn't apply to newcomers, but it doesn't even apply to seasoned hackers like Mike: the BSD style doesn't provide for adequate comments, and so what you see from the code is mainly tactics, not strategy. You miss my point; you don't want to be writing a driver until you know what you're doing. Documentation on an OS' driver interface won't teach you that; it's something that's really only ever gleaned from experience. The problem is, you can't even find what the interfaces are. Reading the code isn't very useful if you can't even find the right place to start from. At least the interface points could be listed, so that someone would know where to begin. Listing the interface points won't help unless you know which ones are relevant to what you're trying to do. I say it again; first you need to know how to write a device driver, then you need to know what the available tools are to get the job done. Having only the latter does not help at all with the former. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: [PATCH] Please test the PS/2 mouse driver patch
I wrote a patch for the psm driver to add support for several PS/2 mice. It is in http://www.freebsd.org/~yokota/ps2mice-24Jan2000.tar.gz. I am attaching README included in the patch. I have the Logitech wireless radio mouse, and I get errors about illegal or unknown PS/2 packets. It's cosmetic, because the mouse works like a charm, but the very first mouse click or move makes it jump across the screen. After that Does this fix address that problem too? If not, could I get you to address this problem? :-) Kees Jan == You are only young once, but you can stay immature all your life To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreBSD 3.3, power off and power button stuff
A few things here. apmd is not the same as apm. So check your /etc/rc.conf to see if you have both apm_enable and apmd_enable set to "YES". apmd is just a daemon to take care of some apm events, but for shutdown -p it's not needed. Try 'apmconf -e' on the command line. If you still get 'apm: can't open /dev/apm: Device not configured' do 'dmesg | grep apm' If that returns nothing your kernel doesn't have APM in it. Check if you went through all the steps of compiling and installing a custom kernel. Or you might get something along the lines of 'apm0 not found at .' in that case your BIOS doesn't have APM enabled. (if it supports it at all) Let me know if this helps at all DocWilco Ralph Seguin [EMAIL PROTECTED] 01/22 12:43 AM Hi. I'm having some difficulty getting APM and power control working in FreeBSD 3.3 I've built a kernel with APM enabled in the config file and enabled it in rc.conf, however apmd says it's starting up, but ps never shows it running. From /etc/rc.conf: apm_enable="YES" bash-2.03# apm -s apm: can't open /dev/apm: Device not configured bash-2.03# ls -al apm* crw-rw 1 root operator 39, 0 Jan 21 15:24 apm crw-rw 1 root operator 39, 8 Jan 21 15:24 apmctl I did a MAKEDEV in /dev, just in case, but the major/minor numbers came out the same. What I'd like to do is have shutdown -p work properly and I'd also like to intercept the power switch so I can shutdown gracefully. Any suggestions are much appreciated. Thanks. -Ralph [EMAIL PROTECTED] __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
-On [2124 10:13], Daniel C. Sobral ([EMAIL PROTECTED]) wrote: As long as a device is just inb/outb (I seem to recall newbus have a replacement for these) bus_space_read_#() / bus_space_write_#() Where # is 1, 2, 4, or 8. But I don't think we support atomic 8 byte atomic reads and writes. -- Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/B-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai When we have not what we like, we must like what we have... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
-On [2124 10:13], William A. Maniatty ([EMAIL PROTECTED]) wrote: Is it possible to get a look at the digital Unix guides, that might be a good starting point. Are they on line (perhaps you have a URL)? http://www.unix.digital.com/faqs/publications/dev_doc/DOCUMENTATION/HTML/Digital_UNIX_Bookshelf.html -- Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/B-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai But Time, keeps flowing like a river (on and on)... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH] Please test the PS/2 mouse driver patch
I have the Logitech wireless radio mouse, and I get errors about illegal or unknown PS/2 packets. It's cosmetic, because the mouse works like a charm, but the very first mouse click or move makes it jump across the screen. After that Please provide the following information so that I can diagnose your problem. 1. Which version of FreeBSD you are using. 2. EXACT product name and the model # of your Logitech mouse. You see, Logitech has produced quite a lot of mice. You can find the name and the model # printed on the label on the bottom surface of the mouse. 3. EXACT error messages you saw. Check /var/log/messages. The error messages may still be there. 4. If you are using FreeBSD 3.X, send me /var/run/dmesg.out and /etc/rc.conf so that I can see how your mouse is set up. 5. If you are describing error when you are using XFree86, send me your XF86Config file too, and tell me the version number of XFree86. Kazu Does this fix address that problem too? If not, could I get you to address this problem? :-) Kees Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
-On [2124 08:01], Chuck Robey ([EMAIL PROTECTED]) wrote: The problem is, you can't even find what the interfaces are. Reading the code isn't very useful if you can't even find the right place to start from. At least the interface points could be listed, so that someone would know where to begin. Working on that. And I am finally getting somewhere. I hope to commit some manpages, very rough for now, somewhere this week. -- Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/B-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai We've laid together in the sun before the mind-rape has begun... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
In message [EMAIL PROTECTED] Jeroen Ruigrok/Asmodai writes: : As long as a device is just inb/outb (I seem to recall newbus have a : replacement for these) : : bus_space_read_#() / bus_space_write_#() : : Where # is 1, 2, 4, or 8. But I don't think we support atomic 8 byte : atomic reads and writes. It isn't so much that "we" don't support atomic 8 byte operations, it is that the busses and cpus don't support these operations... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Warning: xxx sector(s) in last cylinder unallocated
The message comes when you create a new filesystem with newfs. According to page 263 of the "The complete FreeBSD", this is not a problem because the space will be used anyway (how?). I searched the archive, somebody mentioned an option to newfs to use the unallocated space. My understanding is that if there are no bits in the bitmaps corresponding to those sectors, they will never be used. If there are, why newfs prints the warning message? I hope someone will clarify this for me. Thanks a lot. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
-On [2124 19:55], Warner Losh ([EMAIL PROTECTED]) wrote: In message [EMAIL PROTECTED] Jeroen Ruigrok/Asmodai writes: : As long as a device is just inb/outb (I seem to recall newbus have a : replacement for these) : : bus_space_read_#() / bus_space_write_#() : : Where # is 1, 2, 4, or 8. But I don't think we support atomic 8 byte : atomic reads and writes. It isn't so much that "we" don't support atomic 8 byte operations, it is that the busses and cpus don't support these operations... Sorry, mea culpa. It's just that I have been shifting back and forth between NetBSD and FreeBSD and that I see they have bus_space_[read|write]_8 defined and we don't. So my statement was actually more in reflection to NetBSD's support of it. Whether or not they support busses which do 8 byte atomic reads/writes I am not sure of. Thanks for the reality adjustment Warner. =) -- Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/B-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Woe to the vanquished! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
In message [EMAIL PROTECTED] Jeroen Ruigrok/Asmodai writes: : So my statement was actually more in reflection to NetBSD's support of : it. Whether or not they support busses which do 8 byte atomic : reads/writes I am not sure of. : : Thanks for the reality adjustment Warner. =) Yes. Looking at the bus.h in NetBSD/i386 I see: #if 0 /* Cause a link error for bus_space_read_8 */ #define bus_space_read_8(t, h, o) !!! bus_space_read_8 unimplemented !!! #endif The Netbsd/alpha version appears to have it defined. Makes sense when you think about it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
In message 01bf669f$94c4ec70$[EMAIL PROTECTED] "David Schwartz" writes: : The term "maximum" refers to the fact that she can stop waiting earlier if : the package arrives. It doesn't mean she can't wait more than 4 hours. Exactly. She's not letting you down by waiting 5 hours before giving up, or going somewhere else for an hour after the 4 hours are up and then phoning you to say that there was no package. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
David Schwartz once wrote: The man page is correct and the implementation is correct. Several people, said the man pages are broken: Bruce Evans on Dec 28: If timeout is a non-nil pointer, it specifies a maximum interval to wait for the selection to complete. This is a bug in the man page. It is so poorly worded that it is broken. "maximum" here means "minimum" in the case where no selected event occurs. Daniel Eischen on Jan 23: You have to guarantee that the actual time is greater than or equal to the amount of time specified. Warner Losh on Jan 23: : Could you provide the chapter/verse number of : where POSIX spec contradicts the man pages? It : will help me make my case on the TCL forum, : since the TCL developers remain under the : mistaken assumption, that select() may return : earlier, but never later than specified. Somewhere in the archives have a pointer to the unified unix spec for select. Might want to look for it. A useful regular expression might be http://www.*/select.*. This is becoming ridiculous. Somehow, I get a feeling a bunch of people manage to agree with each other on a subject they express exactly opposite opinions. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
* Mikhail Teterin [EMAIL PROTECTED] [000124 12:35] wrote: David Schwartz once wrote: The man page is correct and the implementation is correct. Several people, said the man pages are broken: Bruce Evans on Dec 28: If timeout is a non-nil pointer, it specifies a maximum interval to wait for the selection to complete. This is a bug in the man page. It is so poorly worded that it is broken. "maximum" here means "minimum" in the case where no selected event occurs. Daniel Eischen on Jan 23: You have to guarantee that the actual time is greater than or equal to the amount of time specified. Warner Losh on Jan 23: : Could you provide the chapter/verse number of : where POSIX spec contradicts the man pages? It : will help me make my case on the TCL forum, : since the TCL developers remain under the : mistaken assumption, that select() may return : earlier, but never later than specified. Somewhere in the archives have a pointer to the unified unix spec for select. Might want to look for it. A useful regular expression might be http://www.*/select.*. This is becoming ridiculous. Somehow, I get a feeling a bunch of people manage to agree with each other on a subject they express exactly opposite opinions. The manpage has been updated in -current: If timeout is a non-nil pointer, it specifies the maximum interval to wait for the selection to complete. System activity can lengthen the in- terval by an indeterminate amount. If timeout is a nil pointer, the select blocks indefinitely. To effect a poll, the timeout argument should be non-nil, pointing to a zero-valued timeval structure. If no one objects I'll be committing it to -stable and praying to the gods that this thread dies. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
:The manpage has been updated in -current: : : If timeout is a non-nil pointer, it specifies the maximum interval to : wait for the selection to complete. System activity can lengthen the in- : terval by an indeterminate amount. : : If timeout is a nil pointer, the select blocks indefinitely. : : To effect a poll, the timeout argument should be non-nil, pointing to a : zero-valued timeval structure. : :If no one objects I'll be committing it to -stable and praying to the :gods that this thread dies. : :-Alfred 'nil' ? 'nil' is the designation for an ascii 0, not a pointer. Please use 'null' or 'NULL' -- for example, look at the gettimeofday man page. 'nil' has nothing to do with pointers. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
* Matthew Dillon [EMAIL PROTECTED] [000124 12:59] wrote: :The manpage has been updated in -current: : : If timeout is a non-nil pointer, it specifies the maximum interval to : wait for the selection to complete. System activity can lengthen the in- : terval by an indeterminate amount. : : If timeout is a nil pointer, the select blocks indefinitely. : : To effect a poll, the timeout argument should be non-nil, pointing to a : zero-valued timeval structure. : :If no one objects I'll be committing it to -stable and praying to the :gods that this thread dies. : :-Alfred 'nil' ? 'nil' is the designation for an ascii 0, not a pointer. Please use 'null' or 'NULL' -- for example, look at the gettimeofday man page. 'nil' has nothing to do with pointers. I'll wait for more feedback and include this request in the final update, even if it's the only change. 'nil' doesn't cut it for me either. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreBSD 3.3, power off and power button stuff
'dmesg | grep apm'
If that returns nothing your kernel doesn't have APM
in it. Check if
you went through all the steps of compiling and
installing a custom kernel.
Pretty sure I did all of this correctly.
Mr Brooks gave me a useful pointer: remove disable
from the apm config line. I guess I should actually
READ what I'm doing... :-)
Here's what I've got:
cd /usr/src/sys/i386/conf
/usr/sbin/config -g TESTKERNEL
cd ../../compile/TESTKERNEL
make depend
make all
Then, I FTP'ed the kernel over to the test machine and
did the install line, by hand:
Pilfered from the kernel Makefile:
bash-2.03# cat kinst
#!/bin/sh
chflags noschg /kernel
mv /kernel /kernel.old
PATH=${PATH}:/sbin:/usr/sbin
if [ `sysctl -n kern.bootfile` = ${DESTDIR}/kernel ] ;
then
sysctl -w kern.bootfile=${DESTDIR}/kernel.old ;
if [ -f /var/db/kvm_kernel.db ] ; then
mv -f /var/db/kvm_kernel.db
/var/db/kvm_kernel.old.db
fi
fi
install -c -m 555 -o root -g wheel -fschg kernel /
Or you might get something along the lines of 'apm0
not found at .'
in that case your BIOS doesn't have APM enabled. (if
it supports it at all)
It's an Intel i810E motherboard which has APM support.
Apparently other people have had trouble with shutdown
-p not working in 3.x kernels. Unfortunately, I don't
have the option of going to -current, so I need to get
it going in 3.3-RELEASE.
What files are involved in APM and power control?
Would it be easy to produce a patch to merge in to
3.3-RELEASE?
Does anyone have shutdown -p / halt -p working in
3.3-RELEASE?
Reading the LINT kernel config file, it mentions VM86
being related to apm? Should I be turning this option
on (I'm going to try that as an experiment soon)?
Thanks.
-Ralph
[EMAIL PROTECTED]
__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
routed config file
The following is a sample of our existing network.What we need to happen is all the traffic that is coming from eth2 ( being masq'ed) be sent out router A, and all the rest out router B. Will routed do it, and how? currently the default route is route B and therefore all the outbound traffic goes there. Thanks in advance, Thad Scalf RAF --Network Picture- | | |---| |-| | Router A | | Router B | | 215.178.0.34 | | 40.15.125.250 | |---| |-| || || |-| | eth3eth0| | 215.178.0.3340.15.125.193 | | 255.255.255.224 255.255.255.192 | | | | Linux router | | | | eth2 eth1 | | eth2 - 215.178.0.3 eth1 - 40.15.125.1 | |215.178.0.0/27 40.15.125.0/26 | | eth2:1 - 192.168.0.2 eth1:0 - 40.15.125.65 | |192.168.0.0/24 40.15.125.64/26 | |-| | | | Sub-networks routed and masq'ed from here. | | 215.178.0.64/26 gw 215.178.0.1 ( frame pipe to external networks) | | 10.0.0.0/16 gw 215.178.0.1 | | 192.168.10.0/24 gw 215.178.0.1 | | 192.168.20.0/24 gw 215.178.0.1 | | 192.168.30.0/24 gw 215.178.0.1 | | more networks will be added here... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
Mikhail Teterin wrote: David Schwartz once wrote: The man page is correct and the implementation is correct. Several people, said the man pages are broken: [...] This is becoming ridiculous. Somehow, I get a feeling a bunch of people manage to agree with each other on a subject they express exactly opposite opinions. So shut up and do something about it. So far, we've seen everything *but* patches for the man page from you. Propose a better wording instead of just throwing bricks. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
Matthew Dillon wrote: :The manpage has been updated in -current: : : If timeout is a non-nil pointer, it specifies the maximum interval to : wait for the selection to complete. System activity can lengthen the in- : terval by an indeterminate amount. : : If timeout is a nil pointer, the select blocks indefinitely. : : To effect a poll, the timeout argument should be non-nil, pointing to a : zero-valued timeval structure. : :If no one objects I'll be committing it to -stable and praying to the :gods that this thread dies. : :-Alfred 'nil' ? 'nil' is the designation for an ascii 0, not a pointer. Please use 'null' or 'NULL' -- for example, look at the gettimeofday man page. 'nil' has nothing to do with pointers. More correctly, 'nul' or 'NUL' are ASCII character 0. 'nil' is a pascal phrase that should *not* find its way into the general UNIX lexicon. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
: : : :-Alfred : : 'nil' ? 'nil' is the designation for an ascii 0, not a pointer. : Please use 'null' or 'NULL' -- for example, look at the gettimeofday : man page. 'nil' has nothing to do with pointers. : :More correctly, 'nul' or 'NUL' are ASCII character 0. 'nil' is a pascal phrase :that should *not* find its way into the general UNIX lexicon. : :-- :"Where am I, and what am I doing in this handbasket?" : :Wes Peters Softweyr LLC :[EMAIL PROTECTED] http://softweyr.com/ Ah, indeed! nul/NUL == ascii. 'nil' should removed from our vocabulary. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Performance issue with rfork() and single socketpairs versus multiple socketpairs.
:I've found an odd performance issue that I cannot explain. I'm using :socketpairs to communicate with multiple rfork(RFPROC) processes. :Initially, I used a seperate socketpair to communicate requests to each :... : :Unfortunately, I've found that having a group of processes reading from a :group of socketpairs has better performance than having them all read from :a single socketpair. I've been unable to determine why. I've reduced the :problem down to a simple program, included as an attachment (sorry about :that). The results of two runs of the program: The problem is that when you have N processes waiting on a single socket and you write to the socket, all N processes will wake up even though only one will get the data you wrote. This is very similar to the select() problem -- N processes select()ing on the same descriptor (typically a socket listen descriptor), new connection comes in, all N processes are woken up even though only one's accept() will succeed. As an alternative to socket pairs, I would consider using SysV shared memory and SysV semaphores. Under -current you can use shared file mmap()'s with MAP_NOSYNC as an alternative to using SysV shared memory, but the SysV shared memory calls will be more portable. ( When messing with SysV shared memory the system utility 'ipcs -a' comes in useful ). man -k shm man ipcs -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
On Mon, 24 Jan 2000, Alfred Perlstein wrote: * Matthew Dillon [EMAIL PROTECTED] [000124 12:59] wrote: :The manpage has been updated in -current: : : If timeout is a non-nil pointer, it specifies the maximum interval to : wait for the selection to complete. System activity can lengthen the in- : terval by an indeterminate amount. : : If timeout is a nil pointer, the select blocks indefinitely. : : To effect a poll, the timeout argument should be non-nil, pointing to a : zero-valued timeval structure. : :If no one objects I'll be committing it to -stable and praying to the :gods that this thread dies. : :-Alfred 'nil' ? 'nil' is the designation for an ascii 0, not a pointer. Please use 'null' or 'NULL' -- for example, look at the gettimeofday man page. 'nil' has nothing to do with pointers. I'll wait for more feedback and include this request in the final update, even if it's the only change. 'nil' doesn't cut it for me either. I don't like the first stanza and prefer wording more like what Solaris has for poll(): If none of the defined events have occurred on any selected file descriptor, poll() waits at least 'timeout' milliseconds for an event to occur on any of the selected file descrip- tors. On a computer where millisecond timing accuracy is not available, 'timeout' is rounded up to the nearest legal value available on that system. The "maximum interval to wait for the selection to complete" isn't really the maximum, but more like the lower bounds of the time to wait for the selection. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
: :The "maximum interval to wait for the selection to complete" isn't :really the maximum, but more like the lower bounds of the time to :wait for the selection. : :Dan Eischen :[EMAIL PROTECTED] It's definitely a maximum, because select() can return much sooner if one of the I/O events being waited on occurs. If you call it a minimum you imply that select() will not return until at least the specified amount of time elapses, which is incorrect. Just because it may go slightly over the specified time when no I/O events are pending does not change anything -- FreeBSD is not a hard-realtime system and programmers understand that. If anyone were to actually get confused by this, they have to go back to school. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Performance issue with rfork() and single socketpairs versus multiple socketpairs.
"Scott Hess" wrote: I've found an odd performance issue that I cannot explain. I'm using socketpairs to communicate with multiple rfork(RFPROC) processes. Use 'pipe(2)' rahter than 'socketpair(2)' as both are bidirectional and pipe is a LOT faster. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
On Mon, 24 Jan 2000, Matthew Dillon wrote: : :The "maximum interval to wait for the selection to complete" isn't :really the maximum, but more like the lower bounds of the time to :wait for the selection. : :Dan Eischen :[EMAIL PROTECTED] It's definitely a maximum, because select() can return much sooner if one of the I/O events being waited on occurs. It's not a maximum if you round up to the nearest clock tick. If you call it a minimum you imply that select() will not return until at least the specified amount of time elapses, which is incorrect. Just because it may go slightly over the specified time when no I/O events are pending does not change anything -- FreeBSD is not a hard-realtime system and programmers understand that. If anyone were to actually get confused by this, they have to go back to school. I know all this, but I still prefer Solaris' wording over what we have. If someone is going to change the man page for this, then I suggest we do it in a way that is more clear. "system activity" doesn't seem to me to cover rounding up to the nearest clock tick. I'm happy with leaving the man page as it is also. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Device Drivers
I;d like to start contributing to the project, and I've heard unanimously a good place to start is device drivers. However, I'd like to try something other than sound cards (the only major recommendation I've heard so far) Are there any NICs, or other driver areas where FreeBSD could use some help? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Performance issue with rfork() and single socketpairs versus multiple socketpairs.
"Scott Hess" wrote: I've found an odd performance issue that I cannot explain. I'm using socketpairs to communicate with multiple rfork(RFPROC) processes. Use 'pipe(2)' rahter than 'socketpair(2)' as both are bidirectional and pipe is a LOT faster. Although pipe(2)'s bi-directional capabilities are not standard (I've been stung by this in the past :-() Cheers, -Peter -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How to get a dynamically assigned major number?
Dear kernel device gurus,
I'm trying to get the security/skip port working for 4.0. Right
now it's marked BROKEN due to all the device changes earlier in
the year, and was wondering if someone could help advise me how do
update it..
Below is the current code that works with -stable. How do I get
a major number for the cdevsw I need to add? It looks like cdevsw_add()
no longer treats zero as 'assign me one dynamically'.
I'd really like to get this fixed soon (ie, before 4.0).. I'm sure
it's something simple I'm missing.
Thanks!
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
-- excerpt from current code
struct cdevsw skipdevsw = {
skip_ifopen, skip_ifclose, skip_ifread, skip_ifwrite, skip_ifioctl,
#if 0
nullstop, noreset, nodevtotty,
#endif
skip_ifpoll, nommap, nostrategy,
"skip", NULL
};
static struct cdevsw*old_dev;
static u_long skip_major;
/*
* Handle loading and unloading of the SKIP module.
*/
static int
skip_mod_event(module_t mod, int event, void *data)
{
int error = 0;
dev_t dev;
switch (event) {
case MOD_LOAD:
/* Add character device, getting assigned a major number */
dev = (dev_t) -1;
if ((error = cdevsw_add(dev, skipdevsw, old_dev)) != 0) {
log(LOG_ERR, "skip: can't add device\n");
break;
}
skip_major = major(dev);
/* Initialize SKIP itself */
if ((error = skip_init()) != 0) {
/* XXX should remove char device */
log(LOG_ERR, "skip: init failed\n");
break;
}
log(LOG_INFO, "skip: device major=%lu, driver loaded\n",
skip_major);
break;
case MOD_UNLOAD:
/* Uninitialize SKIP */
if ((error = skip_uninit()) != 0) {
log(LOG_INFO, "skip: uninit failed\n");
break;
}
/* Replace original device driver (if any) */
dev = makedev(skip_major, 0);
(void) cdevsw_add(dev, old_dev, NULL);
break;
default:
error = EOPNOTSUPP;
break;
}
return(error);
}
static moduledata_t skip_mod = {
"skip",
skip_mod_event,
NULL
};
DECLARE_MODULE(skip, skip_mod, SI_SUB_PROTO_END, SI_ORDER_MIDDLE);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Poweroff / power button in FreeBSD 3.3??
Hi. I'm having some difficulty getting APM and power control working in FreeBSD 3.3 I've built a kernel with APM enabled in the config file and enabled it in rc.conf, however apmd says it's starting up, but ps never shows it running. From /etc/rc.conf: apm_enable="YES" bash-2.03# apm -s apm: can't open /dev/apm: Device not configured bash-2.03# ls -al apm* crw-rw 1 root operator 39, 0 Jan 21 15:24 apm crw-rw 1 root operator 39, 8 Jan 21 15:24 apmctl What I'd like to do is have shutdown -p work properly and I'd also like to intercept the power switch so I can shutdown gracefully. Any suggestions are much appreciated. Thanks. -Ralph [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
Mike Smith wrote: Writing documentation is a resource-sucking nuisance; supporting outdated documentation even more so. The BSD driver model is sufficiently simple I think that there might be a compromise solution: when someone learns the interface from analysing the code he might as well document his findings in some way for others to read. This would require minor additional effort. I'm going to try this with CAM in a few weeks and see whether this idea is viable. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
On Sunday, 23 January 2000 at 22:35:53 -0800, Mike Smith wrote: I can't agree with Mike Smith that reading the code is adequate. It certainly doesn't apply to newcomers, but it doesn't even apply to seasoned hackers like Mike: the BSD style doesn't provide for adequate comments, and so what you see from the code is mainly tactics, not strategy. You miss my point; you don't want to be writing a driver until you know what you're doing. Documentation on an OS' driver interface won't teach you that; it's something that's really only ever gleaned from experience. Hmm. I don't really see what your reply has to do with what you quote. I also strongly suspect that *nobody* really knows what he's doing when he writes his first driver, and that it's an interative process to learn how to get there. Most of us were ``thrown in the deep end'', and somehow we learnt to swim. But in detail, what we all did was to look at all documentation we could find, including of course the source code. I didn't say that reading the source code is bad; it's definitely part of it, just not enough. To be fair, this is an experience I've made with multiple operating systems now. FreeBSD is no worse than the others; writing drivers is inadequately described in every system I know. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
On Monday, 24 January 2000 at 2:44:43 -0500, William A. Maniatty wrote: Hi There: Chuck Robey Writes: I know where Mike's coming from. Wait until the next guy posts on the list "I don't really know how to program, but please tell what 'C' is, and how to write a device driver". We had a pretty nasty flamewar over that maybe (I think) 9 months ago, and it still hurts folks, to be accused of conceit, when the guy was asking a grossly unanswerable question, and wouldn't believe it couldn't be boiled down to a 4 paragraph "device drivers for dummies" thing. Mike wants to avoid dealing with a horde of folks like that. I can't really blame Mike, it's impossible to make people understand that you can't boil everything down to a 30 second sound bite. BUT I still wish there was a map to interfaces. Ah! I wasn't aware of this. I would be somewhat thin skinned too, too many requests for a free lunch can be a problem. On the other hand I still think: (i) I'd still like my student to take a crack at it, since he would pick up some understanding of kernel programming by doing it (a good thing!) (ii) the project might help motivated (and good) people pick up FreeBSD kernel programming and (iii) people can be pointed to the manual and told to return if they have a specific question. These were pretty much exactly the reasons I thought of. I was thinking (iii) might be getting your guy to do the documentation :-) Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
On Monday, 24 January 2000 at 2:28:23 -0500, Chuck Robey wrote: On Mon, 24 Jan 2000, William A. Maniatty wrote: Both Chuck Robey and Mike Smith have some points, but that won't stop me from giving my opinion :-). Mike is correct that experience is key to being a solid systems software developer, who writes device drivers. Now the next question is how can someone get experience? By developing systems software (which by the way they should only do if they have experience at it :-)). Traditionally there are two approaches: 1) Have a friend available and bug them for help when you get stuck :-) 2) Read the documentation. 3) Read the code and lose a whole lot of productivity without certainty of figuring it out on your own. 4) Dismiss the whole problem as unmanageable and throw your weight behind a more productive project. I know where Mike's coming from. Wait until the next guy posts on the list "I don't really know how to program, but please tell what 'C' is, and how to write a device driver". We had a pretty nasty flamewar over that maybe (I think) 9 months ago, and it still hurts folks, to be accused of conceit, when the guy was asking a grossly unanswerable question, and wouldn't believe it couldn't be boiled down to a 4 paragraph "device drivers for dummies" thing. Mike wants to avoid dealing with a horde of folks like that. I don't think anybody's picking on Mike, but there are some obvious points here: 1. This isn't an idiot asking inappropriate questions, it's a college professor asking very appropriate questions. 2. Nobody's asking Mike to do anything. I think that one of the problems Mike is showing (and it's not just Mike, but somehow it seems to be his turn to be picked on right now :-) is that it's painful enough to go through the learning experience the first time, and you don't really want to go back and try again and again. Unfortunately, this doesn't make it any less necessary. I was hoping that Bill's student might help create better documentation as well; if he succeeds in that, generations of FreeBSD driver programmers will burn incense at his shrine. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
On Monday, 24 January 2000 at 7:09:35 -0800, Mike Smith wrote: On Sun, 23 Jan 2000, Mike Smith wrote: I can't agree with Mike Smith that reading the code is adequate. It certainly doesn't apply to newcomers, but it doesn't even apply to seasoned hackers like Mike: the BSD style doesn't provide for adequate comments, and so what you see from the code is mainly tactics, not strategy. You miss my point; you don't want to be writing a driver until you know what you're doing. Documentation on an OS' driver interface won't teach you that; it's something that's really only ever gleaned from experience. The problem is, you can't even find what the interfaces are. Reading the code isn't very useful if you can't even find the right place to start from. At least the interface points could be listed, so that someone would know where to begin. Listing the interface points won't help unless you know which ones are relevant to what you're trying to do. I say it again; first you need to know how to write a device driver, then you need to know what the available tools are to get the job done. Having only the latter does not help at all with the former. I'd like you to see you build a timber roofing structure: "Listing the kinds of beam won't help unless you know which ones are relevant to what you're trying to do. I say it again; first you need to know how to build a roof, then you need to know what the available tools are to get the job done. Having only the latter does not help at all with the former." I repeat: before you can do a job which requires tools, you need to be familiar with those tools. How do you get familiar with those tools? You work with them. The first step of familiarity with the tools doesn't make you an expert, but it helps you know what they look like, and when you find yourself up in the roof and trying to join two beams together, you'll at least have an idea which tools might be of use. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
On Monday, 24 January 2000 at 10:04:10 +0100, Jeroen Ruigrok/Asmodai wrote: -On [2124 08:01], Mike Smith ([EMAIL PROTECTED]) wrote: I can't agree with Mike Smith that reading the code is adequate. It certainly doesn't apply to newcomers, but it doesn't even apply to seasoned hackers like Mike: the BSD style doesn't provide for adequate comments, and so what you see from the code is mainly tactics, not strategy. You miss my point; you don't want to be writing a driver until you know what you're doing. Documentation on an OS' driver interface won't teach you that; it's something that's really only ever gleaned from experience. This I agree on with Mike. Writing device drivers isn't like writing an application. In this respect, it is: I understand Mike to be saying "you can't learn by reading, you learn by doing". The documentation I am writing will definately not be a tutorial style piece of documentation, but a reference guide with sufficient background material so that people a bit familiar with FreeBSD on source level (note the ``a bit'') will get enough ideas and clues from it to proceed forwards. I think it would benefit from tutorial style. That wouldn't be enough, but defining the workspace would make people a lot more comfortable. I do not think making it a tutorial will be beneficial in the long run, since I would have to discuss kernel sources, gdb, ddb and a number of other things on the side. And that's a bad idea? I'd disagree. I just know, from experience, that writing a driver involves more than just code. Definitely. And that's one thing you've got to tell the newcomers. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Device Drivers
On Mon, 24 Jan 2000, Nathan Cohen wrote: I;d like to start contributing to the project, and I've heard unanimously a good place to start is device drivers. However, I'd like to try something other than sound cards (the only major recommendation I've heard so far) Are there any NICs, or other driver areas where FreeBSD could use some help? Thanks Check http://www.posi.net/freebsd/drivers/hardware-list.phtml for some hardware people would like to see supported (surely, there is more, but that is a start). Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Analyst / E-business Development, Bell Industries http://www.bellind.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Performance issue with rfork() and single socketpairs versus multiple socketpairs.
Brian Somers wrote: "Scott Hess" wrote: I've found an odd performance issue that I cannot explain. I'm using socketpairs to communicate with multiple rfork(RFPROC) processes. Use 'pipe(2)' rahter than 'socketpair(2)' as both are bidirectional and pipe is a LOT faster. Although pipe(2)'s bi-directional capabilities are not standard (I've been stung by this in the past :-() Neither is rfork()... Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
BPF bug or not?
All, I've just found that read from /dev/bpfX never return EAGAIN/EWOULDBLOCK. It means that when you do a non blocking read and there is no data you will always get 0. Does it suppose work this way? A non blocking read from pipe return EAGAIN/EWOULDBLOCK if there is no data and pipe was opened as O_RDWR, and 0 when pipe was opened as O_RDONLY. Thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: indirection in bus space
Why have two files bus_at386.h and bus_pc98.h? I386_BUS_PIO_IND should be
able to live with I386_BUS_PIO and I386_BUS_MEMIO happily together.
Because they are different in the type of bus_space_tag_t from each
other. It is the u_long in PC/AT and the structure in PC-98. For
example, bus_space_read_1()s of them are:
PC/AT:
bus_space_read_1(...)
{
...
return (inb(handle + offset));
...
}
PC-98:
bus_space_read_1(...)
{
...
return (inb(bsh.bsh_iat[offset]));
...
}
You could set the handle to point to the structure instead:
bus_space_read_1(...)
{
if (tag == I386_BUS_PIO) {
return (inb(handle + offset));
} else if (tag == I386_BUS_PIO_IND) {
struct bus_space_handle_pc98 *bsh = handle;
return (inb(bsh-bsh_iat[offset]));
} else if (tag == I386_BUS_MEMIO) {
...
}
}
-lq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: indirection in bus space
Luoqi Chen [EMAIL PROTECTED] wrote: You could set the handle to point to the structure instead: I think it is difficult to implement such conversion because: - Not only bus space stuff also resource manager stuff need to perform such conversion. - The type of the bus_space_handle_t can by determined only by the bus tag. The isa_alloc_resourcev (new function) cannot modify bus tag because what it does is only to allocate resources and it cannot register the address to the bus_space_handle_pc98. But allocated resources must be stored into bus_space_handle_pc98. ---+--+ KATO Takenori [EMAIL PROTECTED] |FreeBSD | Dept. Earth Planet. Sci, Nagoya Univ. |The power to serve! | Nagoya, 464-8602, Japan| http://www.FreeBSD.org/ | |http://www.jp.FreeBSD.org/| FreeBSD(98) 3.3R-Rev. 01 available! +==+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: indirection in bus space
I think it is difficult to implement such conversion because: - Not only bus space stuff also resource manager stuff need to perform such conversion. Why? Both bus_space_handle_t and bus_space_tag_t are supposed to be opaque types. Resource manager needs not know the implementation details. - The type of the bus_space_handle_t can by determined only by the bus tag. The isa_alloc_resourcev (new function) cannot modify bus tag because what it does is only to allocate resources and it cannot register the address to the bus_space_handle_pc98. But allocated resources must be stored into bus_space_handle_pc98. We could create a new resource type SYS_RES_IOPORT_ARRAY, and intercept it in all isa_*_resoruce() methods. In isa_alloc_resource(), we malloc and return a fake resource record, in which we store I386_BUS_PIO_IND as bus tag and address of bus_space_handle_pc98 as bus handle. And in isa_release_resource(), we first release the underlying resources stored in the bus_space_handle_pc98 record and then free the fake resource record itself. It should be safe as long as we don't manipulate this resource by direct resource manager calls, which we shouldn't do anyway. (or we should implement it at the root bus level, if pci devices in pc98 systems also use discrete port addresses). -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
