link_elf:symol m_gethdr udefined
I get this error when try to load NICs driver kldload if_yk.ko for Marvel Yukon 88E8053 Gigabit adapter on frebsd 5.3 i tryed to recompile kernel with variuos conf but nothing helped and maybe the drive wich i try to use do not fit for 5.3 http://www.syskonnect.com/syskonnect/support/driver/d0102_driver.html i also posted this probelm in questions ML several times but with no repsone so can someone help me pls? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: link_elf:symol m_gethdr udefined
Hi Puramukas, which driver version are you using? Did you get this error message with the standard GENERIC kernel that came with 5.3-RELEASE, or did you get it with your own kernel? By the way, if you get problems with our drivers, please contact [EMAIL PROTECTED] That way we can log problems officially and provide new releases. Cheers, Gerald Puramukas wrote: I get this error when try to load NICs driver kldload if_yk.ko for Marvel Yukon 88E8053 Gigabit adapter on frebsd 5.3 i tryed to recompile kernel with variuos conf but nothing helped and maybe the drive wich i try to use do not fit for 5.3 http://www.syskonnect.com/syskonnect/support/driver/d0102_driver.html i also posted this probelm in questions ML several times but with no repsone so can someone help me pls? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: link_elf:symol m_gethdr udefined
Hi Puramukas, Puramukas wrote: I get this error when try to load NICs driver kldload if_yk.ko for Marvel Yukon 88E8053 Gigabit adapter on frebsd 5.3 ---^^^ This is a Yukon-EC adapter which isn't supported yet for FreeBSD. Where did you get this driver from? The page you cited below doesn't have any FreeBSD drivers for Yukon-EC cards. All the same, you certainly shouldn't get an error message about any undefined functions. The driver shouldn't even attach. Are you _sure_ that the error message is produced when you load the driver and that it isn't caused by something else? i tryed to recompile kernel with variuos conf but nothing helped and maybe the drive wich i try to use do not fit for 5.3 http://www.syskonnect.com/syskonnect/support/driver/d0102_driver.html i also posted this probelm in questions ML several times but with no repsone so can someone help me pls? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sleep select system call not work correctly when linking with multithread libray--FreeBSD 4.5
In message: [EMAIL PROTECTED] River [EMAIL PROTECTED] writes: : This is select testing program-- When time is set backward,the : program linked with -pthread option did not continue printing : anything. But using the program linked with standard library, : printing did not affected by system time backward and all is OK. This is a well know bug. The problem is that the threading library unwisely uses absolute times for the various events... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARG_MAX increase
At 2:11 PM -0500 2/23/05, Garance A Drosihn wrote: At 10:46 AM +0100 2/23/05, Marco van de Voort wrote: I saw ARG_MAX was increased in 6.0. Recently I noticed that the lang/fpc-devel port currently hits the old limit in certain (though rare) cases), and this is annoying. (some testing revealed that half the increase of 6.0 to 131k params is also ok) Any chance ARG_MAX will be upped in -STABLE too? For this specific example, it would be better to fix the port. I should add to this that I have no objection to seeing it raised in 5.x-stable. I'm just saying that even if we do raise it right now, there are a lot of users who will not be helped if the value is only changed in 5.x-stable. I (personally) would rather not see it changed so close to 5.4-release, but it might make sense to increase it in -stable shortly after 5.4-release. I have no opinion on what value it should be changed to, though, if we do increase it. I do not work in that part of the system, so I don't know all the pros and cons that would be involved. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [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: smartmontools vs HP Smart Array 642 controller
On Wed, 23 Feb 2005, Brian Reichert wrote: Does anyone have any experience with smartctl and a HP Smart Array 642 controller? Your problem with smartmontools doesn't seem to be limited to the Smart Array 642, I just tried it on a DL380 G3 with the Smart Array 5i+ and got the same error you did. It appears to be a driver-specific problem. -- Chris Dillon - cdillon(at)wolves.k12.mo.us FreeBSD: The fastest, most open, and most stable OS on the planet - Available for IA32, IA64, AMD64, PC98, Alpha, and UltraSPARC architectures - PowerPC, ARM, MIPS, and S/390 under development - http://www.freebsd.org Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd problem: What SCSI RAID controller compatible with 5.3-Release
Hi Scott, Is there any SCSi RAID controller that works on FreeBSD 5.3 Release. I have tried a couple.like Adaptec 2120S Adaptec 39320A Megaraid LSI-320-1 None of them worked. Any clues. They are under the HCl for FreeBSD 5.3. My configuration is two drives wiht RAID-1. I am using X6DHP-8G SM MB. Also tried the onboard Adaptec 7902, no luck. Thanks in advance. Aman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd problem: What SCSI RAID controller compatible with 5.3-Release
Amandeep Pannu wrote: Hi Scott, Is there any SCSi RAID controller that works on FreeBSD 5.3 Release. I have tried a couple.like Adaptec 2120S Adaptec 39320A Megaraid LSI-320-1 None of them worked. Any clues. They are under the HCl for FreeBSD 5.3. My configuration is two drives wiht RAID-1. I am using X6DHP-8G SM MB. Also tried the onboard Adaptec 7902, no luck. Thanks in advance. Aman The software RAID functionality of the 7902 and 39320A is not supported in FreeBSD. The 2120S and LSI 320-1 should work fine, though. Can you provide details on what problems you had? Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Remote upgrade of 4.X-5.3-Stable
On Thu, Feb 24, 2005 at 12:01:08PM +, [EMAIL PROTECTED] wrote: Date: Wed, 23 Feb 2005 17:06:02 + From: Wouter van Rooij [EMAIL PROTECTED] Subject: Remote upgrade of 4.X-5.3-Stable To: freebsd-hackers@freebsd.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII You did a make buildworld? You just have to boot in single user mode and run mergemaster -p and mergemaster. This doesn't work for the remote update case without physical console access, which he's asking about. Once the machine comes up in single user mode, sshd is not running and there's no way to get into it. Sorry to belabor the obvious. I believe that what's really needed here is to replicate some magic that is done on the first boot after installing FreeBSD on a system. IIRC, there's a special one-time invocation of an rc file - I think after a quick check of /etc/rc that it's rc.early that I'm thinking of. You can put commands in here which are run very early on following the first automatic boot into multi-user of the system, after all virtual drives are assembled but before filesystems are checked and mounted. If all steps of your upgrade script succeed, you can then at the end have the rc.early file rename itself (so it won't run on the next boot) sync the root file system, and reboot again. Obviously you want to test this very carefully, because in a remote environment you will probably get just one shot at having it work correctly; but hopefully this puts you on a workable path. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] Tiki Technologies Lead Programmer/Software Architect I'm gonna tell my son to grow up pretty as the grass is green And whip-smart as the English Channel's wide... -- 'Whip-Smart', Liz Phair ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
sched_4bsd.c Quantum change
Quick question for you hackers! If i wanted to change the scheduler to have a certain marked bad process have a higher time quantum than everyone elses (because it is behaving bad, high mem usage and context switching) to let it run longer to finish faster and avoid context switches and swapping, is this possible in the current scheduler without major changes to it? Right now the scheduler works by having a uniform quantum for all processes, am i correct? Thanks Ash ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Driver Update Disk discussion
The good news is that more and more vendors are supporting FreeBSD directly, many via paid staff to write and maintain drivers, testing labs for QA, and tech support for end-customers. The bad news is that FreeBSD puts up a number of roadblocks that makes their jobs very difficult. While we do a lot to help them get their sources into the tree, the real problem is that we make it very hard for them to provide driver updates that are asynchronous from FreeBSD releases. It is very common for a vendor to want to put out an updated driver with fixed bugs or updated support for a prior release of the OS. The ideal way to do this is by releasing a 'driver update disk' that contains binary modules of the updated driver, along with scripts or instructions for installing it into the system. This system has to be easy and smooth; the vendors often times deal with customers who are not savvy and are in need of an automated, fool-proof solution. It has to be able to cleanly override any existing modules or in-kernel versions of the modules, it has to be able to survive a system recompile, and it has to work in an environment where the system might not be able to boot or install without the updated module. So, in no particular order, the problems that are present right now include: - sysinstall support. Sysinstall has a minor menu for loading KLD's off of a disk, but whatever gets loaded does not get transfered to the new system at all. It's possible to break into a shell and copy and paste the bits by hand, but that's a very poor situation. A framework needs to be in place that lets sysinstall run pre- and post- install actions on a driver disk, with the vendor able to supply custom scripts for these actions. Support for the scripts interacting with the user should also be available (for custom readme's, EULA's, etc). Sysinstall should also be able to arbitrate between a vendor/user supplied driver and the stock driver. The current point where sysinstall allows a vendor disk is too late; the system is already up and all the drivers in the kernel have already probed and attached. This means that overriding an existing driver is impossible. Solving this likely means that the sysinstall kernel is completely stripped down, and all drivers exist as modules that get loaded after sysinstall has started and given the user the option to load a vendor driver. - runtime support. Where will modules be put, how will they be ensured to not collide with the base system modules, and how will the system ensure that they get loaded on every boot. Most of the pieces are in place right now via the loader knowing about /boot/modules, and /boot/loader.conf able to be modified to point to modules in there. What is missing is a formal definition of how these pieces work, and tools to automate and manage it for the user and vendor. - kernel option support. How do we support vendor modules in a kernel that might be compiled with PAE (rather common these days), SMP, MAC, etc. The loader and /boot infrastructure has no concept of this. It's highly important, though. - source code support. A vendor might want to distribute source code for the module that would be picked up in a kernel re-compile. Patching the src/ tree is the only way to do that now, and that creates problems when interacting with cvsup. Solving this would tie into the problem of compiling drivers out of ports/. In fact, a vendor driver, both in source and in binary form, should probably be treated as a port/package, and I describe below. - kernel api/abi. We are trying to keep the kernel api/abi stable now, which helps a lot. However, there is a chance that these could change for legitimate reasons. How do we protect binary-only modules from this? Linux has a fairly draconian system of hashing all of the exported kernel symbols with the kernel options and the kernel major/minor/subminor versions, and making the linker reject modules that don't have the right hash. Should we follow with something similar, or should we have runtime checks that check symbol/structure signatures? Or should we say that we make no guarantees about a binary-only module working on anything but a -RELEASE kernel? - management. How do ge let the user and vendor manage the updated drivers? The vendor might put out a series of updates during the lifecycle of a particular OS release, so we need to provide infrastructure to make this work. The obvious candidate is the ports/packages system, but does that really do all that we need. I need to sit down and think about this a lot before I can say. It would also need to tie in with sysinstall. - kernel namespace. Devclass collisions seem to already be handled gracefully. devfs collisions aren't, and maybe some seatbelts here would be good. Linker symbol collisions are what I really worry about, since they will prevent a vendor from installing an updated driver on top of an existing driver with a overlapping set of non-static
Re: setenv/unsetenv's known memory leak
On Thu, 24 Feb 2005, Dag-Erling Smørgrav wrote: Seán C. Farley [EMAIL PROTECTED] writes: How does this version look? Needlessly complicated. I'd just copy the entire environment into malloc()ed space the first time setenv() or putenv() is called. I like complicated. :) I have written a new version that makes copies of all variables within the environment upon the first run of setenv(). Here are the two versions I have written to stop the memory leak. Old (complex): http://www.farley.org/freebsd/tmp/setenv-1.tar.bz2 New (simple): http://www.farley.org/freebsd/tmp/setenv-2.tar.bz2 Seán -- [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: Re: sleep select system call not work correctly when linkingwith multithread libray--FreeBSD 4.5
Many thanks for your reply. Did the lastest FreeBSD fix this bug? And which version? Because our OS is based on FreeBSD 4.5 and can not port to other FreeBSD easily, Any method to fix it in 4.5? Thanks. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Driver Update Disk discussion
In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : - runtime support. Where will modules be put, how will they be ensured : to not collide with the base system modules, and how will the system : ensure that they get loaded on every boot. Most of the pieces are in : place right now via the loader knowing about /boot/modules, and : /boot/loader.conf able to be modified to point to modules in there. : What is missing is a formal definition of how these pieces work, and : tools to automate and manage it for the user and vendor. Right now /boot/modules is preserved on all kernel installs. What else is necessary? If we have a working packaging system, then installation is taken care of in a manner similar to /usr/local/bin/emacs. A bigger issue is that most of the probe routines return 0 now. This means that only devices that have no support at all in the base kernel can be overridden. I'm working to fix this and hope to get that done before 5.4 at least for PCI and maybe usb and firewire (those probe routines which can be called multiple times), but maybe not for ISA and some PC Card drivers. This likely will be sufficient for any vendor that will want to provide drivers for any modern system. : - kernel option support. How do we support vendor modules in a kernel : that might be compiled with PAE (rather common these days), SMP, MAC, : etc. The loader and /boot infrastructure has no concept of this. It's : highly important, though. The answer in the past is that 'there shall be only one'. SMP doesn't change the module ABI (you can use modules on SMP and non-SMP kernels), but PAE does (since it changes a few key data types). Right now I believe that it is the only option that does change the ABI. Last time I looked, MAC didn't change the ABI at all, but so much has happened there that this may have changed things. The discussions at the time when all this was hashed out for kld(9) and /boot stuff was that it was undesirable to be able to have options that affect the ABI since that would quickly lead into a combinatoric nightmare. Nothing has really changed here: we want to have as few ABIs as possible, ideally 1. I believe that PAE support really should be a seprate kernel architecture and branded as such. Clearly, we can revisit the decisions of the past on this issue. : - source code support. A vendor might want to distribute source code : for the module that would be picked up in a kernel re-compile. Patching : the src/ tree is the only way to do that now, and that creates problems : when interacting with cvsup. Solving this would tie into the problem of : compiling drivers out of ports/. In fact, a vendor driver, both in : source and in binary form, should probably be treated as a port/package, : and I describe below. One does not need to patch the source tree at to pick up ports modules for a kernel rebuild. One can build the ports modules as part of the kernel by simply defining PORTS_MODULES in a kernel config file. In addition, one can specify absolute paths with MODULES_OVERRIDE. One can also build modules outside the tree against a specific kernel (if they somehow depend on the config files). There is one bug with PORTS_MODULES, I'll grant, but that is easy to fix (install should be translated into deinstall/reinstall, but isn't). This bug is easy to work around right now by defining FORCE_PACKAGE_REGISTER, but it should be fixed. : - kernel api/abi. We are trying to keep the kernel api/abi stable now, : which helps a lot. However, there is a chance that these could change : for legitimate reasons. How do we protect binary-only modules from : this? Linux has a fairly draconian system of hashing all of the : exported kernel symbols with the kernel options and the kernel : major/minor/subminor versions, and making the linker reject modules that : don't have the right hash. Should we follow with something similar, or : should we have runtime checks that check symbol/structure signatures? : Or should we say that we make no guarantees about a binary-only module : working on anything but a -RELEASE kernel? Until we have a well defined API that's well documented, I think that any pretense of a guarantee overstates what we'll be able to deliver. Many of the APIs are documented, and most drivers can be written using just these APIs. However, the fussiness needs to change. We also need to have some sort of regression tests There was some work done to make all 5.x drivers depend on a kernel module version 5, but that didn't make it into 5.x due to time constraints on my part (and no one else seemed to be motivated to pick things up). We might want to revisit this. As a practical matter, we can make no guarantees about anything but -RELEASE. In fact, given the total lack of regression tests, it would be hard to tell vendors that we can be sure that their drivers will work. The documentation for the API we have is weak, but we manage to do
Re: sleep select system call not work correctly when linkingwith multithread libray--FreeBSD 4.5
In message: [EMAIL PROTECTED] River [EMAIL PROTECTED] writes: : Many thanks for your reply. Did the lastest FreeBSD fix this bug? : And which version? I believe that 5 fixes this bug, or at least mostly fixes things (since there's at least one pthread API that uses absolute time). However, I've not verified this on 5. : Because our OS is based on FreeBSD 4.5 and can not port to other : FreeBSD easily, Any method to fix it in 4.5? Thanks. The only fix that I could come up with was to base everything on uptime rather than system time. However, I ran into snags because the pthread's API is stupid: int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime); abstime is lame, because it doesn't cope well with system time changing. Your best bet is to make sure that the system time doesn't step after your application starts. This means you'll likely need to wait for ntpd to step the time, or use ntpdate to get things close and tell ntpd not to step things. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: setenv/unsetenv's known memory leak
On Thu, 24 Feb 2005, Seán C. Farley wrote: Here are the two versions I have written to stop the memory leak. Old (complex): http://www.farley.org/freebsd/tmp/setenv-1.tar.bz2 New (simple): http://www.farley.org/freebsd/tmp/setenv-2.tar.bz2 Also, you may find an uncompressed view of the two tar files: Old (complex): http://www.farley.org/freebsd/tmp/setenv-1/ New (simple): http://www.farley.org/freebsd/tmp/setenv-2/ Seán -- [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: Driver Update Disk discussion
On Fri, 25 Feb 2005 12:39, M. Warner Losh wrote: One does not need to patch the source tree at to pick up ports modules for a kernel rebuild. One can build the ports modules as part of the kernel by simply defining PORTS_MODULES in a kernel config file. In addition, one can specify absolute paths with MODULES_OVERRIDE. One can also build modules outside the tree against a specific kernel (if they somehow depend on the config files). I think PORTS_MODULES is a little suboptimal.. I have a patch set which allows a port to install KLD source in a directory and have it picked up during a build/install kernel. This has a few advantages over calling the ports tree from those makefiles. The prime one being that your source code does not change between upgrades without you saying so. This is matters since (for example) the newer nvidia driver does not work on some hardware the old driver does (eg Fx5200 Go). It also means that the kernel build/install does not result in non kernel things being altered. The disadvantage is that the KLD ports need to be modified to install the source code in the right place (not hard) and that you will need to upgrade your ports tree to keep up with ABI changes if you update your source but IMHO it's better to make this sort of action explicit - otherwise the end user is in the position of not knowing what has changed on their system. Also speaking of KLD ports.. I really wish they wouldn't install into /boot/modules (I patch so they don't) as it is a really good way to shoot yourself in the foot during an upgrade :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpj6atSLLZqZ.pgp Description: PGP signature
Re: gcc question
Daniel O'Connor wrote: On Thu, 24 Feb 2005 17:57, Kathy Quinlan wrote: ATM it is written in codevisionAVR which is where the function is called, so I guess for now I will just break the AVR support;) Ahh.. So.. are you talking about getting the coding running _in FreeBSD_ or compiled on FreeBSD and running on an AVR? I am talking about getting the same code running under FreeBSD AND the AVR with minimal changes. Regards, Kat. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.4.0 - Release Date: 22/02/2005 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Driver Update Disk discussion
[[ don't cc freebsd-hackers@ and hackers@ ]] In message: [EMAIL PROTECTED] Daniel O'Connor [EMAIL PROTECTED] writes: : On Fri, 25 Feb 2005 12:39, M. Warner Losh wrote: : One does not need to patch the source tree at to pick up ports modules : for a kernel rebuild. One can build the ports modules as part of the : kernel by simply defining PORTS_MODULES in a kernel config file. In : addition, one can specify absolute paths with MODULES_OVERRIDE. One : can also build modules outside the tree against a specific kernel (if : they somehow depend on the config files). : : I think PORTS_MODULES is a little suboptimal.. How so? : I have a patch set which allows a port to install KLD source in a directory : and have it picked up during a build/install kernel. This has a few : advantages over calling the ports tree from those makefiles. The prime one : being that your source code does not change between upgrades without you : saying so. This is matters since (for example) the newer nvidia driver does : not work on some hardware the old driver does (eg Fx5200 Go). It also means : that the kernel build/install does not result in non kernel things being : altered. How do your patches work? Do they work with multiple kernel trees? : The disadvantage is that the KLD ports need to be modified to install the : source code in the right place (not hard) and that you will need to upgrade : your ports tree to keep up with ABI changes if you update your source but : IMHO it's better to make this sort of action explicit - otherwise the end : user is in the position of not knowing what has changed on their system. I guess I'm a little unclear why this is better or worse than PORTS_MODULES. I guess I'm missing the explicit step, since I only ever update the parts of my ports tree that I'm upgrading with portupgrade. : Also speaking of KLD ports.. I really wish they wouldn't install : into /boot/modules (I patch so they don't) as it is a really good way to : shoot yourself in the foot during an upgrade :( Usually this is only a problem when tracking or jumping to current, but I understand... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Driver Update Disk discussion
On Fri, 25 Feb 2005 14:14, M. Warner Losh wrote: : I think PORTS_MODULES is a little suboptimal.. How so? If you upgrade your ports tree and then rebuild your kernel you may upgrade a port KLD without wanting to. : Fx5200 Go). It also means that the kernel build/install does not result : in non kernel things being altered. How do your patches work? http://www.dons.net.au/~darius/port-kld.diff http://www.dons.net.au/~darius/port-makefile.txt (Rename the later to Makefile and put it in /usr/local/kld) It hooks into /usr/src/sys/modules/Makfile and looks for module directories to build in a certain directory. It [is supposed to] acts like another subdirectory of /usr/src/sys/modules. Do they work with multiple kernel trees? I am pretty sure it does but I haven't explicitly tested it - certainly the source directory doesn't get dirtied by builds. I guess I'm a little unclear why this is better or worse than PORTS_MODULES. I guess I'm missing the explicit step, since I only ever update the parts of my ports tree that I'm upgrading with portupgrade. Ahh.. I NFS mount my ports tree between a bunch of machines they all have WRKDIRPREFIX, and the ports tree is updated each day using cvsup. I don't think this is an uncommon setup but I don't have any evidence. : Also speaking of KLD ports.. I really wish they wouldn't install : into /boot/modules (I patch so they don't) as it is a really good way to : shoot yourself in the foot during an upgrade :( Usually this is only a problem when tracking or jumping to current, but I understand... Yeah usually, but I have had it happen in -stable too (very rare). Even so it can be a pretty big waste of time as a developer when you're tracking current ;) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpFoLjk5BKGB.pgp Description: PGP signature
Re: Remote upgrade of 4.X-5.3-Stable
Gentlemen, is this theme for this list? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
