userconfig.c warnings.
I just noticed these warnings in userconfig.c - I presume they've been there for ages, however I think they should probably be fixed. What is happening is that some devices have descriptions that are too long to fit into the 60 alotted characters, and resultingly are not nul terminated. strcpy seems to be used on these strings later, which could result in trouble, except for the fact that the string is followed by some flags which will usually contain a nul byte. An I confused, or should I send-pr? David. cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing -prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -no stdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../i386/i386/userconfig.c ../../i386/i386/userconfig.c:387: warning: initializer-string for array of chars is too long ../../i386/i386/userconfig.c:387: warning: (near initialization for `device_info [48].name') ../../i386/i386/userconfig.c:396: warning: initializer-string for array of chars is too long ../../i386/i386/userconfig.c:396: warning: (near initialization for `device_info [57].name') To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead? Well, not in theory...
> Another point is that Open Source is virtually synonomous with "Totally > undocumented". The linux community, years into it, are still totally > dependent on Alan Cox to fix drivers properly (mostly because the OS is > completely undocumented and changes are made on a whim regularly). D. This is, not surprisingly, incorrect. I'm mildly curious to know how you arrived at this opinion, but only mildly. I'm sure the list cares even less. Alan can be seen as a concentrator/reviewer for the 2.2.x line. He actually authors a small percentage of the code that passes through him to Linus. fwiw. > Becker continues to be the only one that can properly fix the ethernet > drivers because they are such a mess and poorly documented. And this is even more amusing, showing that you haven't really been paying much attention recently :) -- zach To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead? Well, not in theory...
please move this thread elsewhere immediately- at this point i really don't care where to. several people have requested the same thing over the course of the past couple days, yet certain people insist that they get *one* more comment in on the "topic". this is a list for serious technical discussion of freebsd, not alan cox's exact position in the linux community, or anything else. if you choose to continue a thread in this manner, then perhaps #linux or slashdot trolling would be more suited for your inconsiderate behavior. i get enough mail in the first place, as i'm sure hundreds of other people on this list do. -- --- Ian (Bachtel) Mondragon --- Assistant Network Administrator [EMAIL PROTECTED] MEAS/ECE, Northwestern University (847)491-3691 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead? Well, not in theory...
On Tue, 14 Mar 2000, Ian Mondragon wrote: > please move this thread elsewhere immediately- at this point i really don't > care where to. several people have requested the same thing over the course > of the past couple days, yet certain people insist that they get *one* more > comment in on the "topic". this is a list for serious technical discussion > of freebsd, not alan cox's exact position in the linux community, or anything > else. if you choose to continue a thread in this manner, then perhaps #linux > or slashdot trolling would be more suited for your inconsiderate behavior. > i get enough mail in the first place, as i'm sure hundreds of other people on > this list do. Seconded. Our mail server is waving a white flag, so that makes 3. Not to mention the people who've allready asked and been ignored... -- Lloyd Rennie VBCnet GB Ltd [EMAIL PROTECTED] tel +44 (0) 117 929 1316http://www.vbc.netfax +44 (0) 117 927 2015 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Detecting ECC errors
On Sun, Mar 12, 2000 at 01:11:19PM -0800, Doug Barton wrote: > CC'ing -hackers in case we can scare up some interest . . . > > Mike Smith wrote: > > > > > Hi. I took a look over the archives and noticed this ancient > > > thread. (1998) However, I checked the handbook and LINT for options on > > > how FreeBSD logs ECC errors, but I could not find anything. Has this > > > finally been implemented? Or is there currently no way for the OS to > > > detect the # of corrections / detections of errors by DIMM slot? > > > > You're correct; there isn't. It's a relatively simple task that's been > > waiting for a junior hacker to come along and take it up. It's also > > devillishly difficult to _test_ such code... I just spent some time reading the datasheets for the HX chipset (Intels Pentium) and 440BX chipsets, and playing with pciconf. These chipsets will report the ram configuration in terms banks and amounts, and are capable of telling you where the problem is. In the case of the BX, you can get a specific address, while the HX can only tell you which simm is causing the error. All of the hooks are there for true memory error reporting and scrubbing, at least for the two intel chipsets I've seen. -- Robert Sexton - [EMAIL PROTECTED], Cincinnati OH, USA "They believe in `peace, justice, morality, culture, sport, family life, and the obliteration of all other life forms" - Douglas Adams To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead? Well, not in theory...
At 12:06 PM 3/14/00 -0500, Pedro F. Giffuni wrote: >Please guys, > >Move this intrascendental thread to freebsd-chat ! > >Zach Brown wrote: >> >> > Another point is that Open Source is virtually synonomous with "Totally >> > undocumented". The linux community, years into it, are still totally >> > dependent on Alan Cox to fix drivers properly (mostly because the OS is >> > completely undocumented and changes are made on a whim regularly). D. >> >> This is, not surprisingly, incorrect. I'm mildly curious to know how >> you arrived at this opinion, but only mildly. I'm sure the list >> cares even less. >> >> Alan can be seen as a concentrator/reviewer for the 2.2.x line. >> He actually authors a small percentage of the code that passes through >> him to Linus. Most of the DDI (if you bear to call it that) is not documeneted properly and much of it is in fact wrong. The device driver book was wrong before it hit the stands. The only way I've been able to get answers is to ask him. The docs are ok as long as you are building a "to the spec" ethernet driver, but anything else (all of which use the same interface) its a bit of a crapshoot. Call him a "reviewer" if you will. but none of it works unless he conveys how it needs to be done. Hang out on the lists for awhile...hes the only one with answers to specific coding questions. db To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Compaq Integrated Raid Array
I have some very short term access to a Compaq 8500. The integrated raid array is supported under linux via it's smart array driver. I have a feeling that it should just work with freesd's driver, but "scanpci" shows it using a a vendor id of 0x1000 and a device id of 0x0010. Where in a 4.0 kernel do I stick these so it know's to probe it as an ida device? Thanks, To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Compaq Integrated Raid Array
On Tue, 14 Mar 2000 [EMAIL PROTECTED] wrote: > I have some very short term access to a Compaq 8500. The integrated raid > array is supported under linux via it's smart array driver. I have a > feeling that it should just work with freesd's driver, but "scanpci" shows > it using a a vendor id of 0x1000 and a device id of 0x0010. Where in a > 4.0 kernel do I stick these so it know's to probe it as an ida device? > Try /sys/dev/ida/ida_pci.c. The device ID and vendor id are stored in the IDA_DEVICEID_SMART #define and currently the ida driver has it hardwired to 0xAE100E11. For quick & dirty hack (i.e. if you just want to know if the driver will work with your hardware), try changing the IDA_DEVICEID_SMART #define to 0x1010. 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: Compaq Integrated Raid Array
On Tue, 14 Mar 2000, Kelly Yancey wrote: > On Tue, 14 Mar 2000 [EMAIL PROTECTED] wrote: > > I have some very short term access to a Compaq 8500. The integrated raid > > array is supported under linux via it's smart array driver. I have a > > feeling that it should just work with freesd's driver, but "scanpci" shows > > it using a a vendor id of 0x1000 and a device id of 0x0010. Where in a > > 4.0 kernel do I stick these so it know's to probe it as an ida device? > > > > Try /sys/dev/ida/ida_pci.c. The device ID and vendor id are stored > in the IDA_DEVICEID_SMART #define and currently the ida driver has it > hardwired to 0xAE100E11. For quick & dirty hack (i.e. if you just want > to know if the driver will work with your hardware), try changing the > IDA_DEVICEID_SMART #define to 0x1010. Looking at the Linux driver I don't think its going to be that easy; they have handling for the integrated array that our driver doesn't. -- | 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
Porting linux drivers to FreeBSD
Hi- I found a linux driver for my Xircom PCMCIA ethernet card at: http://pcmcia.sourceforge.org/ Are there any pointers available on porting linux drivers to FreeBSD? TIA- Don To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
LDAP NIS replacement
Hi, New to the list, but I'm looking into developing a way to authenticate and grab user information from an LDAP server compared to /etc/passwd and company, or NIS. I was poking around the library code and noticed that FreeBSD does not have NSS (name service switch) support (otherwise I would use nss_ldap already out there - it doesn't compile under FreeBSD even with IRS use enabled, I've tried ). What would be the best way to write new getpwent(), etc. routines for FreeBSD? I could stick them into a library and have programs that want to use them link to it, but that is a pain (although quite portable :)). I'm working on a PAM system first (yes, pam_ldap is out there, but it sucks, lots of linuxisms), but would be interested getting some work done on this as well. Any thoughts, advice, pointers? Yann To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting linux drivers to FreeBSD
In message <[EMAIL PROTECTED]> "Don Wallwork" writes: : Are there any pointers available on porting linux drivers : to FreeBSD? The xe driver is close to working with current as it is. There is a minor problem with the pccard layer that I've not had the time to commit. If it is for a cardbus driver, there are efforts underway for that as well. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: LDAP NIS replacement
On Tue, Mar 14, 2000 at 04:23:32PM -0800, yramin wrote: > Hi, > > New to the list, but I'm looking into developing a way to > authenticate and grab user information from an LDAP server compared > to /etc/passwd and company, or NIS. I was poking around the library > code and noticed that FreeBSD does not have NSS (name service > switch) support (otherwise I would use nss_ldap already out there - > it doesn't compile under FreeBSD even with IRS use enabled, I've > tried ). What would be the best way to write new getpwent(), > etc. routines for FreeBSD? I could stick them into a library and > have programs that want to use them link to it, but that is a pain > (although quite portable :)). > I'm working on a PAM system first (yes, pam_ldap is out there, but > it sucks, lots of linuxisms), but would be interested getting some > work done on this as well. Any thoughts, advice, pointers? PLEASE use the enter key about every 80 characters... your email looks horrible ;) I'm working precisely on this. I've integrated the NSS functionality from NetBSD into the standard C library of FreeBSD. I'm in the process of rewriting the get* function to use the dispatcher. Once we have that, the way to go would be to have the C library dlopen the required modules as PAM does. Are you sure that nss_ldap doesn't compile on freebsd? I think I compiled it once (and of course it was unusable since FreeBSD lacks NSS). regards, -oscar -- pgp public key: finger [EMAIL PROTECTED] pgp fingerprint: 6D 18 8C 90 4C DF F0 4B DF 35 1F 69 A1 33 C7 BC To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
bsd search
http://www.google.com/bsd I finished it, hope its helpful. -- Dave McKay Network Engineer - Google Inc. [EMAIL PROTECTED] - [EMAIL PROTECTED] I'm feeling lucky... PGP signature
need help
hi everybody i want to hack the ips in the freebsd for a study project,but when i do that , recompiled the kernel , install it ,( in fact what i did is :forrward all the incoming packets in attempt to do load balancing ) but after doing that i can no restart my host , the problem is that is remains forwarding packets , no stop there any suggestion in how can i restart the original kernell , or at least skip this step of keeping forwarding , without having to reinstall all the freebsd thanks ; best regards, To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Vinum encapsulating existing partitions (was: Sysinstall 'A'uto partitioning)
On Tue, Mar 14, 2000 at 12:12:17PM -0800, Greg Lehey wrote: > On Thursday, 9 March 2000 at 11:12:21 +1030, Mark Newton wrote: > > > Another thing which would be useful is the ability to "vinum-ize" an > > existing filesystem without destroying it first. On Solaris and > > IRIX I can do that by creating a logical volume with a single plex > > which just happens to contain the same partition as the existing > > filesystem, thereby wrapping the filesystem in the logical volume. [ ... ] > It's still on my wishlist, though I don't know if I have it on the web > page (and since I'm on the road at the moment, I can't check). My > main concern here is that I want to maintain the device name/drive ID > independence (for those who may not know, you can take the disks of a > Vinum array out, shuffle the device IDs and reboot, and it will still > put the components together in the correct way). IRIX does accomplish this (Solaris ODS doesn't). There are certain features of the way it handles its disks which make that simpler, though: IRIX utilizes a reserved partition on every disk (partition 8) as a "volume header", which must start at sector 0 and can be arbitrarily sized. The volume header contains a disklabel (which starts at sector 0, so it overlays the disk's partition table) and zero or more additional files in a simple filesystem (not a filesystem as such; all files are contiguous, rammed together a-la a tar archive, simple enough for a first-stage bootloader to understand). The most common use for this filesystem is to contain the second-stage bootloader (aka /boot/loader on BSD), but there are other purposes for it as well. One of those purposes is to host XLV volume labels, which are replicated across all disks which participate in XLV volumes. Each XLV volume label contains a unique identifier for the spindle which contains it. That means that the "subdisk ID" equivalent, together with all the other info in the label, is held out-of-band, leaving the partition containing the XLV volume element as a repository for filesystem data and nothing else. The advantage of this approach is, of course, that an XLV volume can "wrap" a preexisting filesystem without destroying it. If I want to grow my /usr partition on dks0d1s6 by using a "spare" partition on dks1d2s0, I can do this: irix# xlv_make xlv_make> volume usr usr xlv_make> data usr.data xlv_make> plex usr.data.0 xlv_make> ve dks0d1s6 usr.data.0.0 xlv_make> end Object specification completed xlv_make> exit Save changes? [n] y irix# [ then modify fstab to mount /usr from /dev/xlv/usr instead of /dev/dsk/dks0d1s6 and reboot. Once I've done that, I'll never need to reboot to manage /usr again; I can perform operations like growing the filesystem onto additional volume elements without needing to unmount it (in fact, some operations will fail to work if the filesystem is unmounted) ] irix# xlv_make xlv_make> ve foo dks1d2s0 foo xlv_make> end Object specification completed xlv_make> exit Save changes? [n] y irix# xlv_mgr xlv_mgr> attach ve foo usr.data.0 VE foo attached to plex usr.data.0 xlv_mgr> show -verbose all [ you'll see that "foo" has been renamed to "usr.data.0.1" ] xlv_mgr> exit irix# xfs_growfs /usr [ /usr is "grown" online (i.e: you don't need to unmount it) ] > The obvious way to > do that is to say "there must be a Vinum partition on this physical > drive, but the subdisk doesn't have to be on it". That could be a > problem for existing disks. Thoughts? A variation might be, "There can be more than one Vinum partition on a physical drive, and Vinum metadata can be kept in a different one from Vinum data." Cheers, - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: LDAP NIS replacement
Perfect ! Please let me know when you get NSS working in the C library, as I am very interested. I tried compiling the copy of nss_ldap from padl.com - in both GNU_NSS mode and IRS_NSS mode. Both crapped out in various places and it seemed such a big chore to try to clean them up, so I stopped. I'm going to get ADP (some 486 in the corner) to 4.0-CURRENT sources, and use that as a reference platform for pam. I'm rebuilding pam_ldap from scratch, as the sources from padl once again passed through too many hands - I think it needs a fresh start. About the e-mail, sorry about that. I was typing away in my ISPs dated webmail system. NPS (Naval Postgrad School, I work there over school breaks) recently installed a new firewall, which blocks port 25, so I'm pretty stuck (their mailserver doesn't do realying :(). Yann On Tue, 14 Mar 2000, you wrote: > On Tue, Mar 14, 2000 at 04:23:32PM -0800, yramin wrote: > > Hi, > > > > New to the list, but I'm looking into developing a way to > > authenticate and grab user information from an LDAP server compared > > to /etc/passwd and company, or NIS. I was poking around the library > > code and noticed that FreeBSD does not have NSS (name service > > switch) support (otherwise I would use nss_ldap already out there - > > it doesn't compile under FreeBSD even with IRS use enabled, I've > > tried ). What would be the best way to write new getpwent(), > > etc. routines for FreeBSD? I could stick them into a library and > > have programs that want to use them link to it, but that is a pain > > (although quite portable :)). > > I'm working on a PAM system first (yes, pam_ldap is out there, but > > it sucks, lots of linuxisms), but would be interested getting some > > work done on this as well. Any thoughts, advice, pointers? > > PLEASE use the enter key about every 80 characters... your email > looks horrible ;) > > I'm working precisely on this. I've integrated the NSS functionality > from NetBSD into the standard C library of FreeBSD. I'm in the > process of rewriting the get* function to use the dispatcher. > > Once we have that, the way to go would be to have the C library > dlopen the required modules as PAM does. > > Are you sure that nss_ldap doesn't compile on freebsd? I think I > compiled it once (and of course it was unusable since FreeBSD > lacks NSS). > > regards, > > -oscar > > -- > pgp public key: finger [EMAIL PROTECTED] > pgp fingerprint: 6D 18 8C 90 4C DF F0 4B DF 35 1F 69 A1 33 C7 BC > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Yann Ramin [EMAIL PROTECTED] Atrus Trivalie Productions www.atrustrivalie.eu.org irm.it.montereyhigh.com Monterey High ITwww.montereyhigh.com ICQ 46805627 AIM oddatrus Marina, CA "All cats die. Socrates is dead. Therefore Socrates is a cat." - The Logician # fortune "To be responsive at this time, though I will simply say, and therefore this is a repeat of what I said previously, that which I am unable to offer in response is based on information available to make no such statement." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
specifying probe order for scsi controllers
so, i have a production system with an ncr0 to which i would like to add an aha0 in addition to the existing controller. when i do this, though, the aha0 comes up before the ncr0, so the numbering on the system disk gets thrown off. i tried changing the fstab entries for the system disk, but the slices for da1s1 weren't MAKEDEV'ed and apparently you can not MAKEDEV the slices within the partition ... perhaps that is because my existing da1 is a dedicated disk? nyways, can I specify the order in which these controllers come up in the system? i had guessed that you could based on the admonition about ISA ethernet probe orders ... but by default the ncr0 is listed first. or is there some way i can config things to keep da0 on the ncr and da1 on the aha? thanks, -danny -- come.to/dannyman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
According to John Polstra: > I have read in several places that only the name "RC4" is trademarked, > and that the algorithm itself is not patented. Is that not the case? That's right. RC4 (aka arcfour in SSH) was a trade secret (so it was not patentable) till someone posted code implementing it on USENET a few years ago... They didn't do that mistake again with RC5/RC6/... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #78: Sun Feb 27 15:32:39 CET 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: specifying probe order for scsi controllers
On Tue, Mar 14, 2000 at 21:47:53 -0800, dannyman wrote: > so, i have a production system with an ncr0 to which i would like to add an > aha0 in addition to the existing controller. > > when i do this, though, the aha0 comes up before the ncr0, so the numbering on > the system disk gets thrown off. > > i tried changing the fstab entries for the system disk, but the slices for > da1s1 weren't MAKEDEV'ed and apparently you can not MAKEDEV the slices within > the partition ... perhaps that is because my existing da1 is a dedicated disk? > > nyways, can I specify the order in which these controllers come up in the > system? i had guessed that you could based on the admonition about ISA > ethernet probe orders ... but by default the ncr0 is listed first. > > or is there some way i can config things to keep da0 on the ncr and da1 on the > aha? Yes. See src/sys/i386/conf/LINT. The section on SCSI devices describes how to wire down disks. The scsi(4) man page also has information on wiring down devices. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
