locking in a device driver (was: use of bus_dmamap_sync)
carrying on this discussion, what would be a good locking mechanism to use to protect tsleep() and other sensitive areas in a driver in freebsd 4.x ? the current code for the driver in 5.x uses mtx_lock and mtx_unlock with some parts even being protected by mtx_lock(&Giant). would the use of simple_lock() or s_lock() do, given that SIMPLELOCK_DEBUG was defined in the 4.x kernel ? the mechanism is actually a pseudo device driver which communicates with the real device driver. the pseudo device driver creates a bunch of /dev/ devices which the userland reads/writes to, and the pseudo device driver then places data in a few buffers. the real device driver then reads these buffers and uses busdma to send the data to the device. reading is done by using busdma to read from the device and then placing the data in these buffers for the pseudo device to return to the userland process. locking in the real device driver uses splhigh/splx, but what locking should be used in the pseudo device driver ? -- Regards, /\_/\ "All dogs go to heaven." [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
compiling the kernel faster
hello everybody, i am new to kernel programming. i am developing a compression/decompression functionality in the ip layer. i want to compile the kernel faster. it would be ok if the kernel doesn't have support for sound devices, or other devices like scsi,usb etc. because i would be using the compiled kernel for network data compression only. how could i do that. which source files and where in the makefiles do i make modifications thanks for any suggestions kamal __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: compiling the kernel faster
At 04:54 AM 10/27/2005 -0700, kamal kc wrote: | hello everybody, | | i am new to kernel programming. | i am developing a compression/decompression | functionality in the ip layer. | | i want to compile the kernel faster. | | it would | be ok if the kernel doesn't have support for sound | devices, or other devices like scsi,usb etc. because | i would be using the compiled kernel for | network data compression only. | | how could i do that. which source files and where in | the makefiles do i make modifications | | thanks for any suggestions | | kamal Kamal, The files you modify to drop stuff out of the kernel are in /sys/i386/conf/ (assuming you are on an Intel platform). Copy the GENERIC file in there to something else (e.g DEVKERNEL), then edit that file. Comment out any drivers you don't need using # (check your dmesg output when you boot to see what drivers the OS is loading for your hardware). Don't comment out anything unless it's obviously something you don't need - doublt check the dmesg for stuff like network drivers, hard drive stuff, etc.) Once you comment out the drivers, you will need to re-compile the kernel. Go into /sys/i386/conf/ directory type this: config DEVKERNEL (using the example above) then change into the directory it shows you (should be something like ../compile/DEVKERNEL or something like that) and type this: make depend && make all install clean that will compile the new kernel and leave it in /boot/kernel (it will also backup your old kernel into kernel.old) go into /boot/kernel/ and type this: strip -s * then reboot using shutdown -r now If all goes well, you should boot to the new kernel. You can use the uname -a command to make sure you are on the new kernel okay. If the machine won't boot, you can boot into single user mode and copy the old kernel back in place. An excellent book on the subject is: Absolute BSD: The Ultimate Guide to FreeBSD (Paperback) good luck. Ray ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
In message <[EMAIL PROTECTED]>, Jason Thorpe writes: > >FWIW, I think a devfs based on our new tmpfs would be better for NetBSD. > I was under the impression that each i-node in tmpfs consumed a fair amount of space, making it a bad match for things like /dev which have very many i-nodes but no actual files. (Well, I've seen glitches on ancient systems where /dev/null got turned into a regular file, leading to amusing messages about "/dev/null: no space left on device"...) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ICC 9 in FreeBSD 6
I'm trying to hack the ICC 8 port files to work with ICC 9 and I was wondering if anyone knows right off the bat whether or not I can use the existing patch files in the "files/" directory? I did some diffs on the newer files and it looks like they should work okay, but I don't know what effect that will have on the installation. At the very least, I'll just copy the patched files so I can revert later, if I want to. Has anyone tried this yet? I'm anxious to get ICC 9 working on my BSD boxes since I got it to work on the Linux box. Thanks! Jon Brisbin Webmeister NPC International, Inc. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: compiling the kernel faster
On Thu, 27 Oct 2005 04:54:10 -0700 (PDT) kamal kc <[EMAIL PROTECTED]> wrote: > hello everybody, > > i am new to kernel programming. > i am developing a compression/decompression > functionality in the ip layer. > > i want to compile the kernel faster. > > it would > be ok if the kernel doesn't have support for sound > devices, or other devices like scsi,usb etc. because > i would be using the compiled kernel for > network data compression only. > > how could i do that. which source files and where in > the makefiles do i make modifications > > thanks for any suggestions Read the handbook - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html Next time remember to post to questions@ when asking begginer questions. Cheers Marcin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
On Oct 26, 2005, at 10:22 AM, Bill Studenmund wrote: In the past, we (NetBSD folks) have talked about a devfs. One issue that has come up (I'll be honest, I've raised it a lot) is a desire to retain permission changes across boots, and to tie devices (when possible) to a device-specific attribute rather than a probe order. The permission thing is solvable using scripts that can fix up the perms after mount. The "nodes named after attributes" thing is interesting... and largely something I'm concerned about with wedges, although in that case, it's pretty easy to handle from within wedges itself. Does FreeBSD's devfs support locators and persistent information? Are there plans to support something like that, if not? FreeBSD's devfs does not, to my knowledge, include the things that you have mentioned above. FWIW, I think a devfs based on our new tmpfs would be better for NetBSD. -- thorpej ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: > > Main features: > > - Implements FreeBSD's devfs on NetBSD. In the past, we (NetBSD folks) have talked about a devfs. One issue that has come up (I'll be honest, I've raised it a lot) is a desire to retain permission changes across boots, and to tie devices (when possible) to a device-specific attribute rather than a probe order. Does FreeBSD's devfs support locators and persistent information? Are there plans to support something like that, if not? Take care, Bill pgpr3OJEGJ3wV.pgp Description: PGP signature
Re: correct use of bus_dmamap_sync
Dinesh Nair wrote: On 10/27/05 04:16 Scott Long said the following: an example would be using (BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE) which would be 0x03 in freebsd 4.x and 0x06 in freebsd 5.x. the gotcha is that 0x03 in freebsd 4.x is BUS_DMASYNC_POSTWRITE. so therefore, BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE will be BUS_DMASYNC_POSTWRITE in 4.x which in the syscall is actually a no op. Yes, that is fugly. Just don't use the | versions for now I would guess. Trying to maintain source compatibility between 4.x and 5.x/6.x will make you encounter a whole lot more problems than just this. could you elaborate on what busdma related problems there'd be, between 4.x and 5.x/6.x ? do, for example, the inner workings of the bus_dma* syscalls work the same on both ? I was speaking about driver code in general. For busdma specifically, the only difference is the extra arguments to bus_dma_tag_create(). Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
Dinesh Nair wrote: carrying on this discussion, what would be a good locking mechanism to use to protect tsleep() and other sensitive areas in a driver in freebsd 4.x ? the current code for the driver in 5.x uses mtx_lock and mtx_unlock with some parts even being protected by mtx_lock(&Giant). would the use of simple_lock() or s_lock() do, given that SIMPLELOCK_DEBUG was defined in the 4.x kernel ? the mechanism is actually a pseudo device driver which communicates with the real device driver. the pseudo device driver creates a bunch of /dev/ devices which the userland reads/writes to, and the pseudo device driver then places data in a few buffers. the real device driver then reads these buffers and uses busdma to send the data to the device. reading is done by using busdma to read from the device and then placing the data in these buffers for the pseudo device to return to the userland process. locking in the real device driver uses splhigh/splx, but what locking should be used in the pseudo device driver ? If you need to protect your pseudodriver from being interrupted by the real driver then you'll need to use the same spl() as the driver. Note that you shouldn't be using splhigh() unless you really know what you are doing. Other than that, there likely isn't anything that you need to do for 'locking' in 4.x. The kernel is non-reentrant there, so you don't need to worry about synchronizing multiple threads. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is it possible to mmap() raw disk device?
Xin LI <[EMAIL PROTECTED]> writes: > When we were trying to make a userland FS application we have > encountered "Invalid Argument" when doing mmap() over an open > descriptor to a disk device. It is not currently possible to mmap disk devices. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devinfo(3) problem...
In message: <[EMAIL PROTECTED]> Daniel Rudy <[EMAIL PROTECTED]> writes: : I analyzed the source code for devinfo(8) and used as an example of how : to use the devinfo(3) library. So I knew it transversed the device tree : once, and my code does it twice, first time to locate (is it there?), : the second time to actually extract the data and use it. Maybe you've found a bug in devinfo then... I don't think anybody has used it like this before. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
In message: <[EMAIL PROTECTED]> Scott Long <[EMAIL PROTECTED]> writes: : Dinesh Nair wrote: : > : > carrying on this discussion, what would be a good locking mechanism to : > use to protect tsleep() and other sensitive areas in a driver in freebsd : > 4.x ? : > : > the current code for the driver in 5.x uses mtx_lock and mtx_unlock with : > some parts even being protected by mtx_lock(&Giant). : > : > would the use of simple_lock() or s_lock() do, given that : > SIMPLELOCK_DEBUG was defined in the 4.x kernel ? : > : > the mechanism is actually a pseudo device driver which communicates with : > the real device driver. the pseudo device driver creates a bunch of : > /dev/ devices which the userland reads/writes to, and the pseudo device : > driver then places data in a few buffers. : > : > the real device driver then reads these buffers and uses busdma to send : > the data to the device. reading is done by using busdma to read from the : > device and then placing the data in these buffers for the pseudo device : > to return to the userland process. : > : > locking in the real device driver uses splhigh/splx, but what locking : > should be used in the pseudo device driver ? : > : : If you need to protect your pseudodriver from being interrupted by the : real driver then you'll need to use the same spl() as the driver. Note : that you shouldn't be using splhigh() unless you really know what you : are doing. Other than that, there likely isn't anything that you need : to do for 'locking' in 4.x. The kernel is non-reentrant there, so you : don't need to worry about synchronizing multiple threads. One thing to also bear in mind is that in 4.x spl locking is a code lock. It keeps multiple 'threads' of execution from entering a block of code. mutexes in -current are data locks. While usually one can think of the two the same, it can trip the unweary up. Locking in 4.x is indeed much simpler. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
On October 26, 2005 10:22 am, Bill Studenmund wrote: > On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: > > Main features: > > - Implements FreeBSD's devfs on NetBSD. > In the past, we (NetBSD folks) have talked about a devfs. One issue > that has come up (I'll be honest, I've raised it a lot) is a desire to > retain permission changes across boots, and to tie devices (when > possible) to a device-specific attribute rather than a probe order. FreeBSD 5+ has /etc/devfs.conf and /etc/devfs.rules which include information regarding permissions and ownership for device nodes under /dev. These files can even be used for creating fancy names for devices using symlinks (like /dev/burner for CD-RW devices, or /dev/floppy and so on). At boot time, /etc/devfs.conf is read, and /etc/devfs.rules is read whenever new devices are attached to the system (I believe that's how it works, anyway). Is that what you're looking for? > Does FreeBSD's devfs support locators and persistent information? Are > there plans to support something like that, if not? -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Scott Long <[EMAIL PROTECTED]> writes: : Dinesh Nair wrote: : > : > carrying on this discussion, what would be a good locking mechanism to : > use to protect tsleep() and other sensitive areas in a driver in freebsd : > 4.x ? : > : > the current code for the driver in 5.x uses mtx_lock and mtx_unlock with : > some parts even being protected by mtx_lock(&Giant). : > : > would the use of simple_lock() or s_lock() do, given that : > SIMPLELOCK_DEBUG was defined in the 4.x kernel ? : > : > the mechanism is actually a pseudo device driver which communicates with : > the real device driver. the pseudo device driver creates a bunch of : > /dev/ devices which the userland reads/writes to, and the pseudo device : > driver then places data in a few buffers. : > : > the real device driver then reads these buffers and uses busdma to send : > the data to the device. reading is done by using busdma to read from the : > device and then placing the data in these buffers for the pseudo device : > to return to the userland process. : > : > locking in the real device driver uses splhigh/splx, but what locking : > should be used in the pseudo device driver ? : > : : If you need to protect your pseudodriver from being interrupted by the : real driver then you'll need to use the same spl() as the driver. Note : that you shouldn't be using splhigh() unless you really know what you : are doing. Other than that, there likely isn't anything that you need : to do for 'locking' in 4.x. The kernel is non-reentrant there, so you : don't need to worry about synchronizing multiple threads. One thing to also bear in mind is that in 4.x spl locking is a code lock. It keeps multiple 'threads' of execution from entering a block of code. mutexes in -current are data locks. While usually one can think of the two the same, it can trip the unweary up. Locking in 4.x is indeed much simpler. Warner I wouldn't characterize spls that way. An spl keeps top-half code from being preempted by an interrupt that would cause bottom half code to run. It's more of a special critical section that a code serializer. It's big advantage is that it doesn't mask out all interrupts, just the ones that you want, and it's much more light weight on x86 that doing explicit cli/sti instructions. It's the BGL spinlock that keeps multiple processes from executing the top half at the same time, and there is no control over that; it's just 'there'. The synchronization guarantees that you have in the 4.x kernel are: 1. Only one process will be executing in the kernel at a time. Multiple processes might be blocked at the same time, but only one will be executing, regardless of the number of CPUs. 2. Only one interrupt handler will execute at a time, and while it is executing there will not be any top half code executing on any other CPUs. 3. Interrupt handlers can preempt a process executing in the kernel unless the appropriate spl mask/level is set. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
On 10/27/05 22:00 Scott Long said the following: are doing. Other than that, there likely isn't anything that you need to do for 'locking' in 4.x. The kernel is non-reentrant there, so you don't need to worry about synchronizing multiple threads. thanx a bunch, scott. it's been a nightmare trying to debug the driver and to try to find out why the driver compiled from the same source tree works on freebsd 5.x and doesnt work at all on freebsd 4.x . so far, i've been gloriously unsuccesful at this, and am getting at my wits end on what to go look at. the userland application uses pthreads, and works like a charm both on 4.x and 5.x without using the device. however, when the device is used, it somehow has synchronization errors on 4.x, leading to timers (created in the userland app) timing out and the like. -- Regards, /\_/\ "All dogs go to heaven." [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
Bill Studenmund wrote this message on Wed, Oct 26, 2005 at 10:22 -0700: > On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: > > > > Main features: > > > > - Implements FreeBSD's devfs on NetBSD. > > In the past, we (NetBSD folks) have talked about a devfs. One issue that > has come up (I'll be honest, I've raised it a lot) is a desire to retain > permission changes across boots, and to tie devices (when possible) to a > device-specific attribute rather than a probe order. > > Does FreeBSD's devfs support locators and persistent information? Are > there plans to support something like that, if not? Well, there are two camps (there may be more, but I can only think of these two) to the locators and persistent info... One is the geom_label route, where the devices self identify, so no matter what adX a device appears as, you can just mount /dev/ufs/fsname... The other of course is to allow you to wire down devices... which some things are better about allowing than others.. like you can wire down da and sio devices... Though one things I miss on FreeBSD that MacOSX has is that when you plug in a USB to serial adapter, MacOSX includes the serial number in the device name: /dev/tty.usbserial-FTC8P121, which is convient... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
On Thursday 27 October 2005 18:10, Bill Studenmund wrote: > On Thu, Oct 27, 2005 at 09:29:52AM +0200, [EMAIL PROTECTED] wrote: > > On Wed, Oct 26, 2005 at 05:48:06PM -0700, Bill Studenmund wrote: > > > The reason I'm interested in locators is so that if devices renumber > > > themselves, the permissions follow. I am assuming, but I think we'd > > > rather not use locators for names (/dev/sd.52004567BA64678D anyone?). > > > But if we can tie the permissions to a locator, then it doesn't matter > > > if it's sd2 or sd12. :-) > > > > I think it does matter, because all userland programs use device names, > > not locators. If permissions are enforced by an userland program, they > > will not follow locators. > > Oh, but part of all of this would be that userland would be able to find > out the locators for a device! It won't work any other way. > I was thinking that one could mount devfs on /dev/dev, and then make some symlinks from /dev/ to /dev/dev/, hence it is not possible to union mount anything on /dev. Then symlinks and permissions can be managed by a daemon reading the configuration from "/etc/devfs.conf", like on "FreeBSD". Another problem about /dev as a file system, is that one will possibly not find all the devices on the system, without being a kernel expert. And the major/minor numering is not easy, like mentioned by someone else. On Wednesday 26 October 2005 02:09, Lennart Augustsson wrote: > You'll never get a driver that looks exactly right for one > OS to work with another, even with an emulation layer. That is what I have done. Remember, my emulator is not sandwitched between the driver and the NetBSD kernel. It is more like something that sits beside the NetBSD kernel. Else this task would be nearly impossible, due to the differences between NetBSD and FreeBSD. So if you put a driver under my emulation layer, it will not be a child of the NetBSD device system, but the FreeBSD device system. > For instance, FreeBSD doesn't have an activate method for > device drivers whereas NetBSD and OpenBSD do. There is no problem adding a "device_activate" method to the FreeBSD drivers, though it will only be used on NetBSD/OpenBSD and alike· In fact, you can add any method you like to any device. > And there are examples of the reverse. So shared drivers > will have some clutter. I see that there are some problems, but no big problems. For example on FreeBSD there is no parent bus_dma_tag for PCI devices. But there is no problem to add something like "device_get_parent_dma_tag(device_t *dev)" that will return "NULL" on FreeBSD and the correct value on NetBSD. Merging these smaller differences will be the least problem. The situation is like this, that having two branches of a driver is double work for the maintainer. And maybe this is the reason some drivers are only available on one system. And when one can spend twice as much time on something, it should be better. Shouldn't it be easier to port kernel software between FreeBSD and NetBSD? When it comes to mutexes I want to say that FreeBSD's "struct mtx" is portable to NetBSD without any problems. But when a NetBSD driver is ported to FreeBSD, it will fall under the Giant lock, possibly forcing other parts of the kernel under Giant aswell. Giant is bad, because it puts a single lock on the kernel. Moving some piece of code out of Giant is sometimes easy, but from my experience, it can require a lot of work. Locking is not just that simple. An advantage about non-tsleep-able mutexes, is that one can warn the user when a function that can sleep is called, depending on the context. This might be as innocent as allocating some memory while holding a mutex, which many think will not cause a sleep. So code using its own mutexes, is really preferred, or is it not so important with mutexes? --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: compiling the kernel faster
On Thu, Oct 27, 2005 at 05:14:51AM -0700, [EMAIL PROTECTED] wrote: > At 04:54 AM 10/27/2005 -0700, kamal kc wrote: > | hello everybody, > | > | i am new to kernel programming. > | i am developing a compression/decompression > | functionality in the ip layer. > | > | i want to compile the kernel faster. > | > | it would > | be ok if the kernel doesn't have support for sound > | devices, or other devices like scsi,usb etc. because > | i would be using the compiled kernel for > | network data compression only. > | > | how could i do that. which source files and where in > | the makefiles do i make modifications > | > | thanks for any suggestions > | > | kamal > > Kamal, > > The files you modify to drop stuff out of the kernel are in > /sys/i386/conf/ (assuming you are on an Intel platform). Copy > the GENERIC file in there to something else (e.g DEVKERNEL), > then edit that file. That's OK, also can take a look into the NOTES kernel config for additional options. > Comment out any drivers you don't need using # (check your > dmesg output when you boot to see what drivers the OS is > loading for your hardware). Don't comment out anything unless > it's obviously something you don't need - doublt check the > dmesg for stuff like network drivers, hard drive stuff, etc.) > > Once you comment out the drivers, you will need to re-compile > the kernel. Go into /sys/i386/conf/ directory type this: > > config DEVKERNEL (using the example above) > > then change into the directory it shows you (should be > something like ../compile/DEVKERNEL or something like that) > and type this: > > make depend && make all install clean > > that will compile the new kernel and leave it in /boot/kernel > (it will also backup your old kernel into kernel.old) Here are new instructions to compile the kernel. Go to the root source directory -- usually /usr/src -- then... make buildkernel KERNCONF=DEVKERNEL But, before making a new kernel, if you add new devices, edit the src/sys/conf/files to add the device properly. > go into /boot/kernel/ and type this: > > strip -s * > > then reboot using shutdown -r now Nope, if you are developing over the kernel _never_ strip the symbol table. Do not use the strip command. Instead, use the kernel config command flag in the DEVKERNEL config file. makeoptions DEBUG=-g This will enable symbol tables on the kernel for debugging purposes ;) > If all goes well, you should boot to the new kernel. You can > use the uname -a command to make sure you are on the new > kernel okay. If the machine won't boot, you can boot into > single user mode and copy the old kernel back in place. > > An excellent book on the subject is: > > Absolute BSD: The Ultimate Guide to FreeBSD (Paperback) > > good luck. > > Ray That's OK Also take a look on the FreeBSD Documetation Proyect. Regards. -- . 0 . | Daniel Molina Wegener . . 0 | dmw at unete dot cl 0 0 0 | FreeBSD Power User ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
In message: <[EMAIL PROTECTED]> Dinesh Nair <[EMAIL PROTECTED]> writes: : the userland application uses pthreads, and works like a charm both on 4.x : and 5.x without using the device. however, when the device is used, it : somehow has synchronization errors on 4.x, leading to timers (created in : the userland app) timing out and the like. libc_r will block all other threads in the application while an ioctl executes. libpthread and libthr won't. I've had several bugs at work that can be traced to faulty drivers and/or faulty APIs that were specified by people who were unaware of this issue... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[PATCH] IPv6 support for ggate
Hi hackers:
Today I had a need to run ggate over an IPv6-only network. I was a
little surprised that it didn't seem to like that, but not discouraged.
So here's a patch that adds IPv6 support for ggated(8) and ggatec(8)
;)
Overview:
* Standardizes on sockaddr_storage for both sockets and addresses
* A few semantic differences for certain functions due to the above
change (ip2str, g_gate_str2ip)
* ggated by default listens on both v4 and v6 sockets (uses select loop
instead of accept loop). You can listen on v4 only with "-a 0.0.0.0"
or v6 only with "-a ::", or of course bind to a specific address
* Use getaddrinfo in place of gethostbyname, and parse addresses with
inet_pton
* All address are stored internally in network byte order now. Mask
comparisons should be independent of byte order since it's purely a
"vertical" comparison.
Things I'm not entirely happy with:
* More AF_INET/AF_INET6 conditional code than I'd have liked to add.
Unfortunately there doesn't seem to be an easy way to be protocol
neutral with a lot of the socket functions.
* The v6 part of countmask is really ugly and complicated. I need to
check the ifconfig source and see if there's any standard way for
converting a /nnn mask to a binary mask.
* When resolving DNS names, it will only use the first entry if there
are multiple. It technically always had this problem, but it's more
noticeable now. Networks are more likely to have names with both a v4
and v6 record than to have multiple v4 addresses. Fixing this the
'right way' would require significantly more invasive changes.
Other than that, I was running with this patch for most of the afternoon
with great success. Now I just need to write a kernel mode ggatec so I
can mount root over ggate :P
-- Craig
diff -ruN ggate.orig/ggatec/ggatec.c ggate/ggatec/ggatec.c
--- ggate.orig/ggatec/ggatec.c Thu Oct 27 22:12:19 2005
+++ ggate/ggatec/ggatec.c Thu Oct 27 22:28:22 2005
@@ -244,21 +244,27 @@
struct g_gate_version ver;
struct g_gate_cinit cinit;
struct g_gate_sinit sinit;
- struct sockaddr_in serv;
+ struct sockaddr_storage serv;
int sfd;
/*
* Do the network stuff.
*/
bzero(&serv, sizeof(serv));
- serv.sin_family = AF_INET;
- serv.sin_addr.s_addr = g_gate_str2ip(host);
- if (serv.sin_addr.s_addr == INADDR_NONE) {
- g_gate_log(LOG_DEBUG, "Invalid IP/host name: %s.", host);
- return (-1);
+ serv = g_gate_str2ip(host);
+ switch(serv.ss_family) {
+ case AF_INET:
+ ((struct sockaddr_in*)&serv)->sin_port = htons(port);
+ break;
+ case AF_INET6:
+ ((struct sockaddr_in6*)&serv)->sin6_port = htons(port);
+ break;
+ default:
+ g_gate_log(LOG_DEBUG,
+ "Invalid IP/host name: %s.", host);
+ return (-1);
}
- serv.sin_port = htons(port);
- sfd = socket(AF_INET, SOCK_STREAM, 0);
+ sfd = socket(serv.ss_family, SOCK_STREAM, 0);
if (sfd == -1) {
g_gate_log(LOG_DEBUG, "Cannot open socket: %s.",
strerror(errno));
@@ -267,7 +273,7 @@
g_gate_socket_settings(sfd);
- if (connect(sfd, (struct sockaddr *)&serv, sizeof(serv)) == -1) {
+ if (connect(sfd, (struct sockaddr *)&serv, serv.ss_len) == -1) {
g_gate_log(LOG_DEBUG, "Cannot connect to server: %s.",
strerror(errno));
close(sfd);
diff -ruN ggate.orig/ggated/ggated.c ggate/ggated/ggated.c
--- ggate.orig/ggated/ggated.c Thu Oct 27 22:12:19 2005
+++ ggate/ggated/ggated.c Thu Oct 27 22:37:55 2005
@@ -68,7 +68,7 @@
time_t c_birthtime;
char*c_path;
uint64_t c_token;
- in_addr_tc_srcip;
+ struct sockaddr_storage c_srcaddr;
LIST_ENTRY(ggd_connection) c_next;
};
@@ -84,15 +84,16 @@
struct ggd_export {
char*e_path;/* path to device/file */
- in_addr_te_ip; /* remote IP address */
- in_addr_te_mask;/* IP mask */
+ struct sockaddr_storage e_addr;/* remote IP address */
+ struct sockaddr_storage e_mask;/* IP mask */
+ unsigned e_prefixlen;
unsigned e_flags; /* flags (RO/RW) */
SLIST_ENTRY(ggd_export) e_next;
};
static const char *exports_file = GGATED_EXPORT_FILE;
static int got_sighup = 0;
-in_addr_t bindaddr;
+struct sockaddr_storage bindaddr;
static TAILQ_HEAD(, ggd_request) inqueue = TAILQ_HEAD_INITIALIZER(inqueue);
static TAILQ_HEAD(, ggd_request) outqueue = TAILQ_HEAD_INITIALIZER(outqueue);
@@ -116,31 +117,71 @@
}
static char *
-ip2str(in_addr_t ip)
+ip2str(struct sockaddr *addr)
{
-
RFC: porting NetBSD fsdb enhancements to FreeBSD
Recently I've had to do some low-level surgery on some disks that have gone bad in order to recover some of the data. This has required me to zero out blocks on disk, patch up the affected files, and pull the data off the disks. I was toying around the with fsdb tool, but couldn't figure out a way to map blocks to inodes (although the 'blocks' command does the mapping in the other direction quite nicely.) Poking around I found that someone has added this functionality (via a "findblk" command) to NetBSD's fsdb (back in 2003!), which I have grafted onto a 4.x box here with relative ease. NetBSD Mailing List Posting: http://groups.google.com/group/mailing.netbsd.tech.userlevel/browse_thread/thread/18acceb04cf5aadb/2a891d67edf9279%232a891d67edf9279?sa=X&oi=groupsr&start=0&num=3) NetBSD CVS: http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/fsdb/fsdb.c.diff?r1=1.24&r2=1.25&f=h Is this something that folks would like to see on FreeBSD? I've got RELENG_5_4 and RELENG_6_0 boxes here in my office so I can whip up the patches and do some testing in short order. Regards, -- Matt Emmerton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
