Re: Automatic updates (was Re: How long for -stable...)
In message [EMAIL PROTECTED] Jordan Hubbard writes:
: I think that we can do a lot with cvsupd. I've used cvsupd to grab
: binaries on an experimental basis and it seems to work great. I've
:
: Hmmm. Does cvsupd also move a target out of the way if it already
: exists and it's in the process of replacing it? What if the target is
: chflag'd but can be unprotected at the current security level?
:
: What I'm trying to say is that if you have "/sbin/init" and cvsupd is
: about to replace it, I would expect the steps to be something like
: this:
:
: Receive new init as /sbin/init.${pid} (or something)
: |
: |+
: | Yes |Yes
: \/ No |No
: Mv /sbin/init.${pid} /sbin/init -- chflags noschg /sbin/init -- Fail
:|
:| Yes
:\/
:Done
:
: If cvsupd does that or can be gimmicked to do that (add
: --potentially-hose-me flag? ;) then I'd say it's a serious
: contender for being part of a binary update process.
I don't know. I seem to recall that jdp told me at the talk I gave
last year that it just wipes the flags completely and doesn't honor
them.
I think it deals well with this, but I've not tried to replace init on
a running system. Given that the Pluto upgrade went well, I'd expect
the answer is yes, it works.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Problems with Serial Console
In message [EMAIL PROTECTED] Daniel Lang writes: : Maybe somehow, /dev/console is redirected to /dev/ttyd0 and : so both don't seem to work. Modem control might be enabled when in fact you have no modem control lines connecteD? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dual console with matrox g400
One might also be able hack the various universal port replicators to allow one to have multiple heads. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dual console with matrox g400
In message [EMAIL PROTECTED] Greg Lehey writes: : Well, you obviously need two keyboards and two mice. I can't think of : a case where that would be useful, but with x2x (in the Ports : collection) you can allow different people access to the same server. In 1990 I shared a Solbourne workstation with a friend. It had two graphics/I/O boards, which ment that you could have two independent video consoles on it at the same time. Worked a whole lot better than one would have expected given the relative primitive tehcnology of the time. Glad to see that PCs are catching up :-) Wanrer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: reseting hardware after apm resume
In message [EMAIL PROTECTED] Brad Guillory writes: : I have a "new" laptop and a few problems related to apm resume. apm on most modern machines is useless. You need to have acpi support for things to work well. Good thing ACPI has been committed. : When I suspend to disk then resume my sound hardware and ls120 : drive no longer work. I was looking for a knob that would let That's because FreeBSD isn't rnning the right acpi routines on resume to turn the hardware back on. : Does anyone have any idea where to find such a knob in : the kernel config or suggestions on how you would like : the knob to work? You might want to look acpi in -current only. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dual console with matrox g400
In message [EMAIL PROTECTED] Greg Lehey writes: : I had a PC with two graphics cards long before that. It was : relatively common to have a machine with both CGA and MDA, and there : were some debuggers which would handle both (debug a full-screen : application with the debug output on the other monitor). True. But I've not seen a PC that could have multiple keyboards/mice until USB came along. Well, I did see some kludges, but they were fairly rare. Now, many different solutions exist that you can mix and match... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dual console with matrox g400
In message [EMAIL PROTECTED] Greg Lehey writes: : Well, multiple mice were never an issue, but the keyboard was. I had : done some thinking about a serial keyboard, but mainly to get away : from the stupid layouts of PC keyboards. Ah, yes. http://www.village.org/~imp/newtkb-1.0.tar.gz... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FireWire Device Driver
In message [EMAIL PROTECTED] "Andrew R. Reiter" writes: : which he gives a major value for the device driver,... and asks when it : should be ready for use with -current. I have emailed the guy from japan : and have received no response... so I am wondering if anyone else knows : what's up with the firewire situation and whether I should go ahead and : pick up work on it? Last I heard Mike Smith and he were cleaning up the code for inclusion in FreeBSD. This was in July or August of this year. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot off USB SanDisk?
In message [EMAIL PROTECTED] David Miller writes: : SanDisk makes a IDE-like flash card one could plug into a $30 USB : flashcard reader. : : Would FreeBSD have any idea how to boot off such a beast? Alternatively, : anyone know of an ISA/PCI adapter with enough bios on it to boot off a : similar flash? You can use a IDE - CF adapter to boot off this device. You can't boot it off via the USB device however. I've been booting FreeBSD off this beast since about 3.2R. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: can't build custom kernel
In message [EMAIL PROTECTED] Len Conrad writes: : First thing: read /usr/src/UPDATING. : : but I'm not UPDATING, I've installed to virgin disk from 4.1.1 iso-image. The problem is that you need to add the ISA compat shims: options COMPAT_OLDISA # compatability shims for lnc, le Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Who broke ls in FreeBSD? and why?
In message [EMAIL PROTECTED] Will Andrews writes: : [ redirected to -hackers ] : : On Tue, Oct 24, 2000 at 12:23:57AM -0700, Jordan Hubbard wrote: : What's wrong with -a? And what the heck does this have to do with : mobile computing? : : -a doesn't disable -A, it adds to it (also shows . and ..). I think : this guy's looking for an option to disable this flag.. no idea why. : One could simply invoke `ls' as a normal user (say, `nobody') if they so : desired. Yes. Last night I misunderstood what he was saying. For normal users, ls -a lists all files, not counting . and .., but for root it does list all files. ls -A lists all files for normal users, but omits . and .. for root. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot off USB SanDisk?
In message [EMAIL PROTECTED] Brian Dean writes: : : You can use a IDE - CF adapter to boot off this device. You can't : : boot it off via the USB device however. : : So does FreeBSD recognize this as 'ad[0123]'? Even if we can boot : from them, I suppose that it would be asking too much to expect any : kind of hot pluggability? It recognizes it ad0, et al. *DO*NOT*HOTPLUG* You will be sorry and replacing hardware. I've blown out 1 IDE controller before I twigged to this fact. :-( At least we could RMA the board. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AW: AW: Accessing the tty structure of an opened device
In message 10553.972652114@critter Poul-Henning Kamp writes: : the time between a pulse and a space often only takes : a few milliseconds. I have to meassure that with : gettimeofday(). : : You will need to do this in a device driver, there is no way you : can reliably measure that from userland. : : Trust me on this: I've tried. We at timing solutions had a heck of a time measuring timing things in userland and it became very easy to do it in kernel land. We used the parallel port to measure out pulses, but the same pps api that Poul should work for the serial port as well. And the advantage of the pps api is that it queues up events (iirc) and counts them so you know if the buffer overflowed and you missed any. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AW: Accessing the tty structure of an opened device
In message [EMAIL PROTECTED] Mike Silbersack writes: : Stop trying to do this; you cannot poll the serial line at anything like : a useful speed to perform IR decoding. The entire approach you're trying : to take is unworkable. : : Hm, it seems like every motherboard made in the last few years has some : hookup for an IR port that will act as com 2. Are the parts for those : available? (Or would alexander be able to adapt his IR device to that : interface somehow?) The IR there is IrDA which is an extreme subset of the possible I/R applications. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: granularity of gettimeofday()
In message [EMAIL PROTECTED] Alfred Perlstein writes: : Gettimeofday will force a check of the system hardware, basically : you should get better than 100HZ resolution with gettimeofday. gettimeofday on many systems do this. There are other, older systems that do not have a high resolution clock to read and rely on timer interrupts to update the clock. These systems limit their gettimeofday reports to 10ms + a "uniqifier" that means two calls to gettimeofday in a row don't get the same value. On FreeBSD, we go ahead and read the timer hardware so you aren't limited to 1/HZ increments. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Broken PCI-IDE RZ1000 ata
In message [EMAIL PROTECTED] Hans Ottevanger writes: : http://www.intel.com/procs/support/rz1000/ According to this, disabling readahead fixes the problem. It also says you need to mask interrupts so that you don't access the register file for the device. Looking at this I'm not sure if you need to implement both workarounds, or just one of them. One workaround is to disable readahead. The other is to make sure that interrupts are masked during disk I/O. That one is likely to be hard if not impossible to implement in FreeBSD. There's also some interaction with the floppy drive as well. However, Soren says that there are other causes for data corruption. I'm inclined to believe him. These chips really suck. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: irq status
In message [EMAIL PROTECTED] Alexander Anderson writes: : I got curious too and decided to join. If you have dealt with Linux, it : has 'interrupts' file in /proc filesystem. It tells you what IRQs are : currently in use and what's using them. Is there something similar on : FreeBSD? vmstat -i Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLD's on ISA bus: how?
In message [EMAIL PROTECTED] Rink Springer writes: : I got the stuff to compile et al, but I cannot get the darned thing to : run as a KLD. FreeBSD doesn't appear to try to probe for the interface : :(. When I tell FreeBSD it's a PCI thing (instead of ISA), it probes for : it... : : How can I fix this? I want my driver to auto-try all parallel port : addresses, but without having to mark it as a PCI device... anyone? In -current you can just add it to the hints file: hint.foo.0.at="isa" Unless you've made it a child of the ppb bus, in which case it should just work because that bus is, afaik, self identifying. You may also be able to get this to work with an identify routine if it will be at a fixed address. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLD's on ISA bus: how?
In message [EMAIL PROTECTED] Sergey Babkin writes: : Maybe I'm missing something but I think that the point of the identify : routine is to discover this address whatever it is, so it does not : have to be fixed. That doesn't work on the ISA bus too well, unless the card can only be in a few places and your probe routine is guaranteed to be "non-destructive" to other cards, which is almost impossible to guarantee. In Rink's case, he's talking directly to the parallel port, so he might be able to meet these guarnatees. : In 4.x if you say in config file : : foo at isa : : and provide the identify routine in the driver the result should be : the same. The "ep" driver does that using a proprietary probe : procedure. Most cards don't have that backdoor. They are either full plug and play, or they are rock stupid. Come to think of it, there are some that are both :-). The foo at isa might not work even in 4.x. It will attach a child with no hints at all, so the probe routine won't know where to look. The identify routine is the only way to deal. In 4.x, you say device ep not device ep at isa iirc. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLD's on ISA bus: how?
In message [EMAIL PROTECTED] Sergey Babkin writes: : Ah, right. I confused it with another case, where the probe routine : tries to look for all possible ports. If I remember correctly, : "aha" is an example of such device. Yes. aha is pushing the upper limits of what is safe to do. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: user-space resource information...
In message [EMAIL PROTECTED] Mike Smith writes: : Well, I'm really sick of people complaining about not being able to get : at the things the resource manager knows from userspace. So I've done : something about it. Cool. I've wanted this for some time now. : 0: Interrupt request lines 0x0-0xf Nuke the leading numbers. No clue what they mean anyway. How are shared interrupts reported? I have several machines that share lots of interrupts. I'd also print decimal for small valued things, like those with a range = 32. : 2: I/O ports 0x0-0x :0: atdma00x0-0xf :2: atpic00x20-0x21 This explains why the pccard code was, for a time, trying to assign 0x10-0x1f for a device I plugged in... :-) :0: sysresource0 0x0-0x9 :1: vga0 0xa-0xb active shareable :3: sysresource0 0xcd000-0xc :5: sysresource0 0xe8000-0xe :6: sysresource0 0xf-0xf3fff :7: sysresource0 0xf4000-0xf7fff :8: sysresource0 0xf8000-0xf :9: sysresource0 0x10-0x7ff : 11: fxp0 0xe300-0xe3000fff active : 13: sysresource0 0xfffe-0x This looks a little ugly as well, but I don't have a better format. I'll dink with things and see if there's any way I can improve the output. How hard would that device tree be now? Or is there extra hair that's needed for that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLD's on ISA bus: how?
In message [EMAIL PROTECTED] Rink Springer writes: : I've got a probe, attach and a dummy identify procedure for my driver : now. When I load the KLD, my identify procedure gets triggered, but the : probe procedure doesn't! Why? Can someone help me? I've tightly used : aha_isa.c as a help... for some reason, FreeBSD doesn't appear even to : CALL the probe thing! Are you actually adding a child device in the identify routine? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLD's on ISA bus: how?
In message [EMAIL PROTECTED] Rink Springer writes: : I'd like to point out that I'm writing a KLD driver, so the problem : shouldn't be in the kernel, correct? Yes : Why is this? Aha.c does an ISA auto-detect, which I want to do too... : why does it work for AHA and not for me? I'll need some code to look at. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLD's on ISA: another problem
In message [EMAIL PROTECTED] Rink Springer VII writes:
: static void
: dl_identify (driver_t* driver,device_t parent) {
: device_t t;
:
: printf ("DL: IDENTIFY\n");
: t = BUS_ADD_CHILD (parent, 0, "dl", 0);
: bus_set_resource (t, SYS_RES_IOPORT, 0, 0x378, 3);
: bus_set_resource (t, SYS_RES_IRQ, 0, 7, 1);
: }
You need to check to see if the child is already there or not before
adding it.
: But upon loading, it *CRASHES* (!) FreeBSD after the dl0: DONE thing...
You shouldn't hold any resources after your probe routine. You must
free them. It is also generally a bad idea to store things in softc
in probe as the device framework is free to destroy the softc iirc.
Make sure that your softc size is specified properly, otherwise you
may crash.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: KLD's on ISA bus: how?
In message [EMAIL PROTECTED] Sergey Babkin writes: : Hints file is only in -current (AKA 5.0). In 4.x the kernel config : file contains this information (which I guess is of no use for : KLD drivers). Probably you can do a likewise thing in 4.x with : sysctl variables. I've ported the meat of the 5.x hints stuff to 4.x for Timing Solution's embedded products. It works great there so I sometimes forget that it isn't in stable. Maybe I should MFC after 4.2 release. All that I merge does is if there are hints in the boot environment, it sets them. It doesn't do all the rest of the stuff Peter did to -current. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLD's on ISA bus: how?
In message [EMAIL PROTECTED] Rink Springer VII writes: : Yes... is that bad? It was the only way to get BSD to probe it. You should do this only if you haven't done it already. : On the sidenote, my BSD box totally CRASHES after I attach the device using the : ether_attach call... any idea why? I've had this problem in the past. Usually it is due to not giving the softc the right size in the device declaration because I copied it from somewhere that didn't use a softc and specified a '1'. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel stack size?
In message [EMAIL PROTECTED] Jacques Fourie writes: : Would it be possible to pre-allocate a block of memory : and then "switch" stacks in my interrupt routine? This : may be far off, but my only other option is going : through ~1 lines of code and examining all places : where local variables are declared. If I could somehow : do this in a different way, it would really help a : lot. 10k lines in an interrupt routine sounds to be way more work than you want to do in an interrupt routine. Maybe you could use a work queue and deal with it that way. There isn't much I can do to help you with the local variable issue, since it sounds like this code is just flat ill suited for the kernel. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: printf()
In message [EMAIL PROTECTED] Zhenhai Duan writes: : Does the kernel function printf() flushes the output immediately, or it is : possible some data is buffered somewhere and gets lost without printing : to the console? like the corresponding funtion in the c library. Yes. It can be buffered, but that's a driver level thing. I've seen serial consoles where things crashed after a printf I put in and never saw. I've not seen anything similar on video consoles. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Legacy ethernet cards in FreeBSD
In message [EMAIL PROTECTED] "Koster, K.J." writes: : 3Com 3c503ISA I think so. The ed driver supports this : DEC EtherworksISA : DEC DE205 ISA don't know about these. lnc driver supports them maybe ? : SMC EtherEZ ISA ed driver. : RealTek "TP-Link" PCI Don't know about this one. : As far as I've been able to determine, none of these work properly. In : particular, the RealTek card gets detected and pretends to work, but loses : the link after a bit (The link status LED goes out, and I need to reboot the : box.) Read Bill Paul's glowing reviews of the realtek hardware in the rl driver :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: printf()
In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
: printf("foo do foo\n");
: crash_here();
: printf("after the crash\n");
:
: And never see the statement "foo do foo\n";
: Is that correct?
Yes. But I had a lot of printfs in the code that I was debugging and
the last few wouldn't be printed before the crash.
But this was on a serial console where I had printed transmit fifo
size.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: What about rc.shutdown.local?
In message [EMAIL PROTECTED] Jan Grant writes: : It _is_ trivial, but you miss my point: I run several things at startup : that rely on a database service (which needs to be launched first). When : they shut down, the DB must still be running (it's taken down last). So : using a *.sh pattern for startup and shutdown scripts doesn't satisfy my : requirements. Right, that's why there's someone doing an evaluation of the NetBSD startup code to see how well it will work for exactly this sort of situation. Until that evaluation/proof of concept is complete, it would be premature to talk about changes to the FreeBSD system since the NetBSD one already copes with exactly this sort of situation. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLDs and PCI?
In message [EMAIL PROTECTED] "Chris Ptacek" writes: : I am working on a KLD for a PCI device. My problem is I can't find how to : call the probe and attach calls during the load for a PCI device. I have : looked in the /usr/src/sys/pci directory and haven't found any KLDs to use : as an example. What are the steps I need to take to handle a PCI device in : a KLD? Are there any examples I can look out? It just works for PCI in 4.0 and newer. : Oh yeah, I am doing this for a FreeBSD 3.x system (I know, but is needed for : this project, it will be ported to 4.x later) Ah. Well, that's different. You should be able to look at the if_* directory because it has klds in 3.x and they seem to get their probe routines called when loaded after boot. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pci bus enumeration cdevsw indexing
In message [EMAIL PROTECTED] Robert Lipe writes: : Is there a "normal" way for a conforming driver to walk the busses, : pluck out bus number, slot number, device id, subsystem id, and all that : traditional stuff, or do I just need to carve up pci.c and build my own : interface to do it? You may need to carve up pci.c, but there will likely be resistance to such a change. You rarely, if ever, need to do this from a driver. : Also, I have a question on loadable character devices. Is there a way : to avoid the hard-coded major numbers in the cdevsw[] entry that's : passed? It seems like make_dev() should be able to roam cdevsw, find : an empty slot, and create the dev nodes for me. I'm envisioning a very : dynamic system with lots of modules (enough that we really don't want to : allocate them with a human involved) being popped in and out and would : like to not handle the major number management and inevitable conflicts : on my own. No. Get a major number from us and avoid confusion. Or wait for 5.0 and devfs. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: C and C++ on FreeBSD
In message [EMAIL PROTECTED] Thierry writes: : We are implementing our OS modem on FreeBSD, but lot of our sources : have writen in C++. Is it possible to compile the FreeBSD kernel in : C++ to include our driver ? Yes and No. If you use only the bare minimal subset of features for the C++ and avoid the problem areas of the language, you might be able to. But you'd have to add new and delete support to the kernel's library. That should be almost trivial. The problem areas definitely include exceptions, some automatic memory allocation (where temporary variables are malloced), large objects appearing on the stack (because the kernel stack is so small). I don't know if ctors for static objects would be called in the kernel. Templates might also be a problem, but they might not. Years ago I was able to do some very simple C++ in the kernel, but never integrated the support. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: C and C++ on FreeBSD
In message [EMAIL PROTECTED] Peter Dufault writes: : C++ work in an embedded system. Exceptions had already been given : up on. The ctors/dtors are handled with "munch" style tools : (from vxWorks land) that generate construct/destruct : vectors that you'll probably then hook in with kernel modules. Yes. You could easily hook them into the sysinit facility with relative ease. You'd need to do a trick similar to the setdefs trick we do now (which was based on what munch from cfront land used to do). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Moused doesn't reinitialize mouse after removal and reinsertion...
In message [EMAIL PROTECTED] Dave Howland writes: : pain, albeit not completely unbearable. Anyone have any theories on how we : could get moused to a) detect the mouse being unplugged and reinserted and : b) reinitialize the mouse after this happens? Here's some fun info type : stuff (in case it'll help)... With all due respect, pay the extra money for the electric switch. You will burn out your keyboard and mouse ports if you aren't careful. They aren't designed for this sort of hot plugging. I used to think it was OK to do this, but I've had too many keyboard and/or mouse controllers die of the years connected to a mechanical switch to really trust them. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changing a running process's credentials
In message [EMAIL PROTECTED] Peter Pentchev writes: : There are situations (at least I could think of some :) where it is necessary : to change a running process's credentials. I'm thinking specifically of the : effective UID and GID, but I might have to tinker with the real and saved : UID's, too. setuid doesn't work for you? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changing a running process's credentials
In message [EMAIL PROTECTED] Peter Pentchev writes: : Hmm.. I've also received two private mails so far, pointing me to setuid(). : The problem is, I want to force a new UID on *another* process without : its knowledge. setuid() only works on the process invoking it, so : both the 'force' and the 'without its knowledge' part fall by the wayside :( I think the reaction to this by the security officer team would be a) extreme and b) negative. The security implications are huge. : The security implications I meant have to do with the ability to provide : either a tool or a sysctl to change the uid of any running process : on the system - that would have to include stringent controls on exactly : who and why uses this tool/sysctl. I have some ideas about this, : but they need some more grinding before they're ready to be tossed : at the world for discussion (and dissing ;) I'd make it a full syscall, not just a sysctl. I'd also make sure that only root and no body else could use it. Maybe I should back up a step and ask what it is you are trying to accomplish here. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changing a running process's credentials
In message [EMAIL PROTECTED] Alfred Perlstein writes: : Unless this syscall was restricted to root, or a small subset of : uid's it would cause some severe security issues from my point : of view. Even the small subset of uids would be highly suspect. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: scheduler activations in FBSD5.0?
In message 001d01c04fdc$9e2e2e80$020a@mike "Daryl Chance" writes: : Is there a FreeBSD 5.0 Stable or is there only a current : and stable reserved for the current release version (4.X). STABLE is reserved for those branches that have had a release on them. Since there's been no 5.0 release yet, it doesn't have a STABLE version. That's why it is called -current. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
In message [EMAIL PROTECTED] Andrew Gallatin writes: : I'd vote for leaving the access permissions as is. I'd agree with that. We don't know that all PCI hardware will not cause problems when arbitrary locations in config space are read. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard driver docs
In message [EMAIL PROTECTED] Willem van Engen writes: : I'm writing a pcmcia device driver for the PhyDAS system used in our university : for measurements. I have been searching the internet for information on : programming a driver on the pccard bus, but I haven't found any good overview : of a pcmcia driver (well, the 'FreeBSD device driver writer's guide' on : http://people.freebsd.org/~erich/ddwg/ddwg.html seems useful, but currently : it's mostly empty). : If you know useful information about programming drivers on the pccard bus, : please share it with me. I know. Usually I just follow if_ed or if_ep as an example. For the most part things are done for you so there's very little pccard specific code. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard driver docs
In message [EMAIL PROTECTED] Julian Elischer writes: : Of course of someone who knew about pccard would add the appropriate code to the : example driver.. That would make things too easy :-) Seriously, however, in 4.x and earlier it would be no different. In 5.x there's a new requirement for self identification that is used by NEWCARD, but not by OLDCARD. As soon as that settles down, I'll put it into the sample driver. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Support for Syba pci multi i/o card?
In message [EMAIL PROTECTED] John Hay writes: : Does anyone know of patches or something to support these cards? The cards : that I have is by Syba Tech and is a 4 x serial and 2 x parallel port pci : card. It has 2 winbond W83877TF 2 x serial + 1 x parallel port "superio" : chips and some pci glue. The card has 0x400 bytes of io space, as big as : the isa io area. Also from what I understand they all share one interrupt. I have some really bad patches for a similar card. : If there aren't any patches I might look at adding support for it. Probably : only the serial ports, because that is what I need. I would like some advice : on how to do it though. I had a look at the sio driver and it has support : for a few pci cards, but it looks like they are single serial port cards : and not dual or quad. So how should I go about getting the sio probe and : attach to do more than one serial port per pci card? I'm not sure this is the right way to do that. I believe that the right way is to create an attachment for this that attaches N devices. I had some preliminary code that did this, but it has decayed too much so I lost it. Basically: pci0 --- multi-io0 +--- sio0 +--- sio1 +--- sio2 +--- sio3 +--- ppc0 is what I had in mind. Multi-io would register an interrupt and dispatch it to the interrupt to each of the sub devices as necessary. There are other cards like this that also have an extra interrupt register that says which sub device interrupted. I also think that the isa sio multi-port cards should be handled in a similar way. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
In message [EMAIL PROTECTED] Matt Dillon writes: : : -b 16384 -f 4096 -c 159 : I think Bruce swears by 4K (page-sized) fragments. Not a bad : way to go. I use 2K because I (and others) put in so much hard work : to fix all the little niggling bugs in the VM system related to partial : page validation and, damn it, I intend to use those features! At the other end of the spectrum, 32M [sic] and 64M [sic] disks work well with -b 4096 -f 512 -c 10 But I tend to do what phk has done with the large -c flags on my insanely-sized, rediculously-cheap XXG IDE drives. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Support for Syba pci multi i/o card?
In message [EMAIL PROTECTED] Mike Smith writes: : If there aren't any patches I might look at adding support for it. Probably : only the serial ports, because that is what I need. I would like some advice : on how to do it though. I had a look at the sio driver and it has support : for a few pci cards, but it looks like they are single serial port cards : and not dual or quad. So how should I go about getting the sio probe and : attach to do more than one serial port per pci card? : : As Warner suggested, you probably want to create a "bus-like" device that : looks to the sio/ppc drivers like an ISA bus, and then forcibly attach : the relevant sio/ppc instances as children of this device. sio doesn't care what bus it attaches to, so long as it can get its resources. ppc still has some isa specific calls in it, but those map to bus generic ones so would just work. I've been holding off working on this until I saw what haked out of the bus unification work that Matt Dodd has been working on. I think he's mostly done, but I wasn't sure enough of that to proceed. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Support for Syba pci multi i/o card?
In message 92918.976225307@critter Poul-Henning Kamp writes: : There is a PR already with a patch for some multiport cards... Yes. I'm aware of that patch... But I don't like it because it doesn't use the multiio pseudo-bus thing that I talked about. Bruce also has some style concerns with it :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
In message [EMAIL PROTECTED] "Chad R. Larson" writes: : Has the core group ever weighed in on this? Does the BSDi merger : change any of the FreeBSD focus with regard to other hardware : architectures? Core, per se, hasn't. There's a very strong history in this project that if a port is supported, breaking it is unacceptible. FreeBSD has moved beyond intel only, and we need to deal with that, even if there are things we can get away with on i386 and can't on other platforms. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Partial start on pci + serial/parallel cards
OK. I have a partial start on the serial/parallel cards. It isn't attaching anything yet, but should give people an idea on the direction I'd like to head. As part of this work, I'll likely remove pci attachment of sio, and change it to puc. puc is the name NetBSD uses (I snagged the tables and some code from NetBSD's puc driver, btw) so I kept using it. I'll also need to add puc attachments to sio and ppc drivers. I'll also need to add the bus resource allocations stuff so that the client drivers can just use bus resource 0, ala isa. I think that Matt Dodd's recent work makes this relatively easy, but haven't had a chance to look at that closely. Again, this is preliminary and posted for commentary only. I wanted to get this out. http://people.freebsd.org/~imp/puc.tar.gz Comments and patches welcome. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes: : ported to every hardware platform under sun, and we do not go out of our : way to provide security. Thus, NetBSD and OpenBSD have the edge on us on What? I don't see how you can say that about security... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCTP implementation and pccard.conf change for Cisco 802.11B 340 series cards
In message [EMAIL PROTECTED] Jonathan "\"Taz\"" Mischo writes: : #Cisco 340 series 802.11B wireless NICs : card "Cisco Systems" "340 Series Wireless LAN Adapter" : config 0x5 "an" ? : insert /etc/pccard_ether $device : remove /sbin/ifconfig $device delete This already appears to be in -current. Thanks for the entry none the less. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Partial start on pci + serial/parallel cards
In message [EMAIL PROTECTED] Nicolas Souchu writes: : looking at the code. I'd also think about moving it to dev/ppc with a : ppc_isa.c and ppc_puc.c. : : This is something I don't understand. If ppc_puc is a PCI driver why don't : you put in the pci directory and let ppc_isa in isa one? Because in FreeBSD you put all the files for a driver in one directory. In NetBSD you'd do things the way you are talking about. sio and ppc break this rule right now. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Partial start on pci + serial/parallel cards
In message [EMAIL PROTECTED] John Baldwin writes: : : On 12-Dec-00 Warner Losh wrote: : In message [EMAIL PROTECTED] Nicolas Souchu writes: : : looking at the code. I'd also think about moving it to dev/ppc with a : : ppc_isa.c and ppc_puc.c. : : : : This is something I don't understand. If ppc_puc is a PCI driver why don't : : you put in the pci directory and let ppc_isa in isa one? : : Because in FreeBSD you put all the files for a driver in one : directory. In NetBSD you'd do things the way you are talking about. : sio and ppc break this rule right now. : : ...and npx; fd; joy; psm; various ISA portions of vga, syscons, and atkbd; : intpm; meteor; agp; all the PCI network drivers; etc. :-) Yes. I wasn't planning on moving them. But not all the pci network drivers break this rule. vx, at the minimum, follows the new guidelines. The "common sense rider" on this rule has been don't move anything just to move it. Move it when it makes sense to move it. Many drivers have been moved out of isa/* or i386/isa/* to this new location when they grow another bus attachment (usually for pccard). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syscall assembly
In message [EMAIL PROTECTED] Marc Tardif writes: : So why is %esp displaced by 16 bytes when only 8 bytes : are necessary (4 for $0 and 4 for $.LC0)? And couldn't : the compiler use a single instruction such as : subl $16,%esp or addl $-16,%esp? Are two instructions : used for pipelining purposes, where subl is synchro- : nised with the first pushl and addl with the second : pushl? gcc tries to align stack to 16 byte boundaries as a speed optiminzation. Why it doesn't do this in one instruction is beyond me. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: very big mail spool directory
In message [EMAIL PROTECTED] Tony Finch writes: : Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: : : If you only have half a million users, pick a prime number K close to : the square root of the expected number of users (724 in your case - : closest primes are 719 and 727), create that many bucket directories, : and place each user in bucket ID mod K. : : Why a prime number? All you need is an even spread, and given that : user IDs are usually allocated sequentially any modulus will do. Because Knuth has shown that prime numbers give the best spread in hash lookup tables. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
In message [EMAIL PROTECTED] "Pedro F. Giffuni" writes: : There was somone looking at the NetBSD code with hungry eyes but I : never heard anything more... check the archives. Last I heard, only the MIPS based PDAs were supported by NetBSD/hpcmips. I know that there are some efforts to make things run on sh3 machines and there's been talk about the arm as well, but I don't think they have been committed to the tree just yet. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
In message [EMAIL PROTECTED] Robert Swindells writes: : As far as I can tell, the hpcmips kernel reuses the WinCE MMU : translations; all the arm32 ones rely on a bootloader to map RAM : to 0xf000. The hpcmips kernel doesn't do that. The hpcmips loader does that. Once the stuff is loaded into memory, the kernel takes over. Part of that takeover is blowing away the TLB. Once the tlb has been reset, the old WinCE mappings are gone for good. : I mainly want the NetBSD SA-11x0 port to work on our own hardware : where I can just put a different image into flash, so I am not looking : at supporting loading on top of WinCE. OK. The reason that the hpcmips guys went that was was that there's a huge number of WinCE devices, some of which you can get very cheaply, that do not have the option of Flash at all. WinCE is in Mask Programmable Roms. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Partial start on pci + serial/parallel cards
In message [EMAIL PROTECTED] Nicolas Souchu writes: : I'm sure that this subject has been discussion many times on the lists. : I'm also sure that there's a good reason for this, otherwise it wouldn't be : your choice (you is the team). But as it is the opposite of my personal : feeling, could you give me one reason for this in few words? The basic reason for having the dev/foo thing was so that you don't have to hunt over the entire tree to maintian your driver. All the files are in one place and you can easily find them. : Is it for maintainance purpose, so you can remove the whole driver if : not anymore supported for example? NetBSD is architecture independent : oriented, so I guess their choice is also good from there point of view... NetBSD took the view that you have a core driver and then a bunch of bus attachments. The affinity is stronger to the bus code than to the device code so they built the separation they did that way. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
In message [EMAIL PROTECTED] Wes Peters writes: : NetBSD? They have existing ARM and "hpc" ports, this would be a merging : of the two... I didn't think that NetBSD had a hpc port. They have an hpcmips port in the tree, as well as other hpc ports not yet committed (hpcsh3 has been seen in the mailing lists as well as hpcarm, but the latter was a theoretical name for the port at the time). There's an unofficial recognition that hpcFOO means "Runs on WinCE machines for the FOO processor" but so far hpcmips is the only one in the tree. There was also talk about an ipaq or ipaqarm port that would be like the ipaq linux port and take over the machine entirely. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Support for Syba pci multi i/o card?
In message [EMAIL PROTECTED] "Matthew N. Dodd" writes: : On Thu, 7 Dec 2000, Warner Losh wrote: : I've been holding off working on this until I saw what haked out of : the bus unification work that Matt Dodd has been working on. I think : he's mostly done, but I wasn't sure enough of that to proceed. : : If you mean the generic resource list function stuff then yes, I'm : done. That work is non-impacting and is only useful in that it provides a : way to eliminate duplicated code. : : Or was it something else you were talking about? That is the stuff I was talking about. Cool. I'll likely be lookly to use it very soon :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Request for review of newfs update
I've made the following change to newfs man page locally. Please comment upon the style of the change as well as its technical accuracy. Style comments should be sent to [EMAIL PROTECTED] with [EMAIL PROTECTED] cc'd (I'm not on doc@). Technical content comments should be sent to [EMAIL PROTECTED] The change does two things. First, it removes the warning about not being able to boot off file systems that aren't 8k/1k. There was a thread here that reported this was no longer the case and that both 4k and 16k block sizes work. The second change gives an example of using a 16k block size and a 4k fragment size with 100 cylinders per group with a note that this is expected to give better performance for large file systems. Comments about changing the default should go to /dev/null, or be discussed under a different thread. :-) Warner Index: newfs.8 === RCS file: /home/imp/FreeBSD/CVS/src/sbin/newfs/newfs.8,v retrieving revision 1.28 diff -u -r1.28 newfs.8 --- newfs.8 2000/11/20 16:47:42 1.28 +++ newfs.8 2000/12/17 06:15:48 @@ -335,18 +335,20 @@ .El .Sh EXAMPLES .Pp +.Dl newfs -b 16384 -f 4096 -c 100 /dev/ad3s1a +.Pp +Creates a new ufs file system on ad3s1a. +.Nm +will use a block size of 16384 bytes, a fragement size of 4096 bytes +and have 100 cylinders per cylinder group rather than the defaults. +These values are tend to produce better performance than the defaults +for file systems larger than about 5 gigabytes. +.Pp .Dl mount_mfs -s 131072 -o nosuid,nodev /dev/da0s1b /tmp .Pp Mount a 64 MB large memory file system on /tmp, with .Xr mount 8 options nosuid and nodev. -.Sh BUGS -The boot code of -.Fx -assumes that the file system that carries the -kernel has blocks of 8 kilobytes and fragments of 1 kilobyte. -You will -not be able to boot from a file system that uses another size. .Sh SEE ALSO .Xr fdformat 1 , .Xr disktab 5 , To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes: : What do folks think about : : 1)if (data) : free(data); : : versus : : 2)free(data); : : versus : : 3)#define xfree(x) if ((x) != NULL) free(x); : xfree(data); Number 2. ANSI-C (aka c89) requires that free(NULL) work. We shouldn't go out of our way to pander to those machines where it doesn't. Number 1 is my second choice assuming for some reason number 2 isn't an option. Number 3 is the same as #2, imho, except that it gratuioutsly uglifies the code by the introduction of a non-standard API and an additional macro. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes: : I hate to give up a line for : : if (data) : free(data); : : but neither do I care for ``if (data) free(data);''. I guess if I : were writing several statements like that in a single file, I would : consider the macro route (e.g. xfree). No offense, but this strikes me as a premature, sub-micro optimization. I doubt that you could measure any difference between if (foo) free(foo); and free(foo); in the real world. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Writing Device Drivers
In message [EMAIL PROTECTED] Julian Elischer writes: : I have the pci/isa driver skeleton pretty up-to-date, but it doesn't : have any DMA example code, nor does it have any sample code for : pccard or cardbus . Aren't there two kinds of DMA that we need to worry about? Those that are "isadma" where you have to program the DMA controller, and the more conventional DMA where the device becomes the bus master and the bytes just appear in host memory? Also, cardbus should be a 1 liner. I'll add that to your examples. Do you want to review them, or can I just do this and any other tweaks that might be necessary? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes: : None taken. It is however a simple and safe optimization, with no : apparent downsides. It has the same attraction as using bit shifts : instead of multiplication/division, or saving the value from a function : call that will be needed again later, even if you know the function call : is trivial. You are trading a test against zero and code obfuscation against a function call. The function call is typically much less than even a multiplication or division would be. You get clearer, easier to read code that is smaller by allowing free to do its job and not trying to optimize things. : I doubt that you could measure any difference between :if (foo) free(foo); : and free(foo); : : in the real world. : : This is probably correct for most applications. : : Nevertheless, I tend to write it that way at times -- maybe because it : seems so natural to me to ask `do I need to free this thing?' -- and : that gets translated directly to code. I guess I tend to think 'This needs to be freed, let free deal with the details so I won't have to be bothered with them.' Function abstraction is supposed to be about hiding details that don't matter. And in my opinion, this is one of those details. I've also seen code written where this sort of thing was taken to an obscene degree where you'd have 10-30 layers all making the same validity tests to ensure the data was really really good when it was impossible to get down more than a layer or two and have it be bad. Before you say that more tests are good, I cleaned up this mess and was able to reduce 5 overlay regions (yes, 5!) on a pdp-11 fortran monster due to systematically eliminating them (well, I ifdef'd them out (we wrote a fortran preprocessor, but that's another story)). The code went from something like 500k to 225k by removing the redundant tests through all the layers. I know this is an extreme example, but it does go to show that sometimes these tests can be rather signficicant. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes: : Ever notice that you tend to send more email when you should be studying : for a final? That's why Style(9) wars break out this time of year. :-) : /* Case 1 */ /* Case 2 */ : if (data) vs. free(data) : free(data); : : I don't see that Case 1 obfuscates anything. In some cases I find it : clearer: Case 1 implies that maybe no memory was allocated. Case 2 : seems to imply that memory was indeed allocated. Depends on the reader. case 2 to me says "free the memory, if there's any to free". This encapsulates case 1 better than having it be explicit. : I happy with the opinions I've received. Based on them, I seem to be in : the minority of preferring `if (data) free(data);' in some cases. OTOH, : our code base speaks differently than the email I've received -- `if : (data) free(data);' seems to be used quite alot. I will probably : continue to use it the way I have before -- to make it clear that there : may or may not be memory to free at this point. The if (data) free(data); is the dusty deck problem, also known as the dead hand of the past problem. Back before ANSI-C (in the mid 1980's), some frees would core dump on free(NULL), while others would accept it. ANSI-C dictated that it should be accepted and nothing should happen. All code wasn't changed over night. This is the same reason that we have the uglification of __P() in our tree too. Compilers were slow to adpot ANSI-C (no called iso-c or c89) so allowances needed to be made for the multiple environments the code would work in. Now that KR is totally dead, except maybe on Bruce's machines, the need for it no longer exists. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: National Semiconductor 82c168/82c169 driver
In message [EMAIL PROTECTED] Doug Luce writes: : I haven't been able to find a driver for this ethernet card, so I'm : working on porting the Linux driver over. It seems to have "natsemi" : coded in as the default device mnenomic. Is it a good idea to pull this : name directly over to FreeBSD? So my Ethernet interface would be natsemi0 : instead of fxp0 (for an Intel card)... natsemi is likely too generic a name for this one ethernet card. What if the sio driver had been called natsemi since the original 8250 was made by natsemi (well, given the part number, it looks like a intel part. The all 16550 data sheets I've seen are from natsemi only). I'd be tempted to call it nse (National Semiconductor Ethernet). But that might be too generic. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
In message [EMAIL PROTECTED] "Michael C
. Wu" writes:
: IIRC, NetBSD doesn't have the newer StrongARM SA-11xx ports.
: And that's why we have to work from ARM/Linux.
In conversations that I had with an unnamed vendor a while ago, the
newer parts should be just a few days of casual effort to incorporate
into NetBSD. The glue chips for the eval boards likely would be more
work, but the mods for the new CPU would be farily minimal.
: With PicoBSD not working very well in -CURRENT and the advent of
: large sized flash media (SANDISK/CompactFlash, SmartMedia).
: Can we begin to maybe have a "make buildsmallworld" target?
: (i.e. a combination of NO_STATIC=yes and other suitable options)
Maybe. I have a script that will effectively do a installsmallworld
target. The guts of the script are a for loop that does
(cd $FreeBSDSrcDir
make -m ${FreeBSDSrcDir}/share/mk -f Makefile.inc1 \
hierarchy DESTDIR=$1 NOMAN=yes
(cd etc ; make -m ${FreeBSDSrcDir}/share/mk \
distribution DESTDIR=$1 NOMAN=yes)
for i in ${FreeBSDProgramDirs}; do
echo "== $i"
test -d $i
(cd $i ; make -m ${FreeBSDSrcDir}/share/mk \
install -DNOINFO -DNOMAN DESTDIR=$1 -DNOPROFILE)
done)
which lets you tweak things to year heart's delight. Every time I go
to put this script up, I run into the "oh, but I want it to do X Y and
Z before posting." problem. Maybe I should just post it.
: In addition, -CURRENT has become very much larger. I know about
: the "embedded systems are customized, so cut it down yourself"
: argument. However, what if it's still large after we cut it down
: to the bare minimum? Also, what about /dev/random seeding problems?
There are lots of ways to seed /dev/random in an embdeeded system.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
In message [EMAIL PROTECTED] "Michael C . Wu" writes: : Do you use the gcc embedded optimizations? No. Not directly. My install script assumes that : | which lets you tweak things to year heart's delight. Every time I go : | to put this script up, I run into the "oh, but I want it to do X Y and : | Z before posting." problem. Maybe I should just post it. : : Just an idea/question: : Can we possibly use crunchgen to generate a big binary for userland tools : only? Then we can drop in new binaries with ease. No. I will not do that. The biggest reason is that it is an unbelievable PITA to manitain if you have other applications to load onto the box that are outside of the FreeBSD tree. I tried doing that once upon a time and found that with shared libraries for everything, and 16M or larger parts that it wasn't necessary at all since the savings was so meager. : However, I think that simply buying a 100mb SANDISK is easier. :) If you need 100MB parts, you are doing something wrong. We're running on 32M parts with 10-20M free depending on the application(s) we layer onto the device here at Timing Soltuions. And that's without using filesystem level compression. If we could run only out of memory, we'd be able to fit on a 8M part with room to spare. 1.44MB is too small, but 16M is way fat. The base system is a smidge over 7M. You could trim that to about 6M for standard /etc/rc files and about 4M if you roll your own and use the tineware tools from PicoBSD and don't need anything else (eg router, ppp-on-a-stick, etc). Our application requires a control program that's fairly large because it has a lot to do, which is why we chose the 32M parts. Also, for a long time the smallest flash I could build was 16M before we put anything else on it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
In message [EMAIL PROTECTED] "Michael C . Wu" writes: : Would 20mb be a comfortable target for : "make buildsmallworld installsmallworld" ? The build would have to : be interactive. And the interactive build can record all the : options/choices done by the user for future builds. That : leaves room for everyone to use at least 4mb on 24mb CF media, : and 12mb on 32mb CF media. I don't wnat it to be interactive at all. I would support having a configuration program that would be interactive, but the install should just do it. I also do not expect to have a special buildsmallworld target. Just a smallinstall target since there are many tools that should be built that I don't want to short circuit. Installing just a subset isn't a problem at all. There are also some minor problems in the current build system that need to be reoslved for having a runtime-only install for some components. These are mostly nits, but they can be worked around. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
In message [EMAIL PROTECTED] "Michael C . Wu" writes: : It was my understanding from BSDCon2000 that we are targeting : more platforms. It is my sense of core that core would support new architectures if they make sense. To make sense, the architecutre must be widely deployed (or about to be widely deployed). It must have enough brains that a port can be undertaken w/o rewriting large parts of the system (the MMU requirement). It must have enough of a life to make it worth while. And it must have a base of users that are willing to support it in the long haul. By long haul, I mean multiple years. StrongARM generally fits into this model. What is lacking is a good prototype. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KB problemo.
In message [EMAIL PROTECTED] David Preece writes: : At 17:00 22/12/00 -0500, you wrote: : On a reboot I get : bp, then keyboard not found or keyboard error. So, yes : as mentioned just recently on this list, hard switches are _BAD_. : : So the keyboard controller's toast, is that what we're saying? Presumably : you've tried connecting the keyboard directly to eliminate the all too real : possiblity that it's the switch that's broken? I've found that when the keyboard controller goes like this, it usually isn't the keyboard controller per se. On my older 486 machines I have seen this many time, but swapping out the 8242 keyboard controller chip doesn't seem to help : Configuring FreeBSD to run headless is a FAQ on -small, and consequently I : did a page about it that's hosted in half a dozen places none of which : I can remember. Search the archive on -small for "headless" and you'll be : there. echo -h /boot.config Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kvtop() on alpha question
In message [EMAIL PROTECTED] Alexander Langer writes: : How can the if_ed driver work on FreeBSD/Alpha, if it uses kvtop(), : but kvtop() is only defined in sys/i386/i386/vm_machdep.c? I don't think it can. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fd1720
In message Pine.GSO.4.30.0012232213090.16265-10@gecko [EMAIL PROTECTED] writes: : On the same token, I have tried to get a (possibly used) 2.88 MB Floppy : drive for some time. It seems to me that even though all floppy : controllers support these babies, nobody makes them. There are one or two : places that seem to offer old supplies, but to ridiculous prices. FreeBSD : comes with a bootimage for 2.88 MB drives, so it would be nice to me to : find one of these babies. Has any body had experiences with this? The last three times I've gone looking for 2.88MB floppy drives, I found that their price was about that of the 100MB ZIP or the SuperFloppy (which was 105M or 150M, I forget which). It was just easier to use an atapi ZIP drive. Then I discovered CF to IDE adapters... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
In message [EMAIL PROTECTED] Alex Belits writes: : That is your interpretation. Other lawyers disagree with that : interpretation. : : No. This issue was beaten to death multiple times, large amount of : software was created based on this, and its legality is absolutely : certain by now. No. You are wrong. The fact that large amounts of software has been created is irrelevant. The GPL has never been adjudicated. That is a fact. There is no legal precidence for any interpretation of its terms and conditions as written. Until such time as it is adjudicated, it is in doubt. Like you've said, this had been beaten to death many times and I am quite sure of my facts. I have consulted with atterneys investigating the possibility of using Linux and the GPL of the kernel was a deal killer. It was too legally risky because of the multitude of authors of Linux and the possible interpretations of the GPL. That is the big reason why Linus' pronouncement on the issue isn't necessarily legally firm ground. Any one of those authors could challenge someone's non-release of driver source and have legal standing to bring the suit. Unless you get all the authors to agree to that, and the matter will remain risky. The number of times it has been beaten to death on Usenet is irrelevant. There are a number of issues that have been beaten to death and have none-the-less proven to be wrong. What is true is that if it is adjudicated and it goes against the conventional wisdom, a lot of people are going to be very unhappy and forced to do things they do not wish to do. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fd1720
In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : Any specific types/brands of CF to IDE adapter you could recommend? Either the tapr one (http://www.tapr.org) or the pcengines one (http://www.pcengines.com) work. Timing solutions builds its own, so I don't know of others. The one on the pcengines web site can be hard to find, but it is there if you dig. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs. Linux, Solaris, and NT
In message [EMAIL PROTECTED] "SteveB" writes: : Since when is a product required to be open source to run on Linux? My : understanding was if an product was developed using GPL'd code or : libraries then that product is required to offer source. But just an : application running on Linux, that will kill Linux. It isn't. We were specifically talking about device drivers that are linked into the Linux kernel. : So are programs that run on Linux required to be open source? I need : to know. No. Normal programs are not, unless, as you say, they use code that requires otherwise. That part is believed to be safe, even by the more paranoid attorneys that I've talked to. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : JKH, DG, CORE respond. Core does not respond to mail not directed to it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
In message [EMAIL PROTECTED] Peter Seebach writes: : In message [EMAIL PROTECTED], Warner Losh writes: : In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes : : : : JKH, DG, CORE respond. : : Core does not respond to mail not directed to it. : : Not to mention the basic problem of J Random Luser *demanding* a response. If anyones makes a request of core, there is an appropriate forum for that request. We try to answer all requeries we get. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
-BEGIN PGP SIGNED MESSAGE- In message [EMAIL PROTECTED] "David O'Brien" writes: : Uh no. Both of those times that a message was sent out, it wasn't even : signed (Internet on 10 May 2000 and Freefall on 16 May 2000). Hop on : over the the archives on hub.freebsd.org and get your facts straight. : The Internat change didn't even list the new key. And the best we've : ever done is in the "HEADS UP: New host key for freefall!" thread started : by Peter Wemm on Tue, 16 May 2000 23:26:33. For freefall's key, Kris personally sent out a message with the key, signed with the FreeBSD Security Officer key. I don't recall what he did with Internat. This was done in extremely short order after the change. In the discussions that happened aferwards, it was agreed that future heads up messages would be pgp signed by the admin and that the security officer would verify things if there was any doubt. Warner P.S. I don't know where cvs-committers archives lives, so I could't provide message numbers. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBOkg0F9xynu/2qPVhAQHi3QQAlsrgJVAWawcixxsdXTwMx5hUBEj78p82 oi2AxxnnvgD43/MC0tvlZ44j3cUcrrekcx6xZS3Z5V5KQs0nuKGBFht8NNMVVNoe F9cy+eDAnXd9GiJM4wrjyoHJRyngCJYAL79V7fIo4yieBGHZ66LJXWOVlUiXgU/W pnQgyfhP9WA= =X1V1 -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard issue
In message [EMAIL PROTECTED] Andreas Brodmann writes: : The pccardd is running. Does anyone know what it could be : or what I have to do to get any output from pccardd (even : if it was just saying "i don't know the card you inserted"). Interesting. You should at least get a card inserted message in dmesg. Try to find a irq that is free to use for a management IRQ. You might also see if there are conflicts with the memory space or i/o space that might be causing this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
In message 005801c07037$47ae6ea0$[EMAIL PROTECTED] "Renaud Waldura" writes: : I've got that FreeBSD gateway in a corner at my house, it works fine dandy : but the constant noise (whirring fans, hard drives) gets on my nerves. : : What solutions have people explored to quiet down a computer system? (actual : experience will be preferred over wild speculations). I'm already aware of : PicoBSD, but I need more storage than just a floppy. Has anybody : experimented with RAM cards? How about noise-proof enclosures? CF cards work great! They are very very quiet in normal operation. In fact, if they do make noise, you have a really big probelm. :-) I've also seen custom cases that have sound dampening devices but still have sufficient airflow for most people's needs. I've also run in a production machine where the edict was there shall be no fans with big honkin heat sinks (like 9inch long 2inch high fins running the length of the unit). But that was a fairly custom design and would likely be too expensive for the normal user (we also had to underclock the CPUs as well to meet temperatuere specs). I have a buddy that swears by the following low-tech cheap technique: Take a big cardboard box. One that is about 1.5x the size of the box you want to keep quiet. Knock a few holes in the box (small holes seem to work best, and only a few of them) and put the cardboard box over the unit. Hav ethe cables come out the bottom. Put something heavy on the box to keep in in place, but not too heavy since this is just cardboard. But I've not tried this. You'll likely need to try this on a system that doesn't run hot to start with. The CF cards will help a lot with the heat (since they run at room temperature, if they are generating heat, again you have big problems). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
In message [EMAIL PROTECTED] Wes Peters writes: : We have several NIC's around here (the New Internet Computer, see : http://www.thinknic.com/ for details) and will be adding a couple of these : so we can boot FreeBSD or NetBSD on them in the next little while. A NIC : running FreeBSD on a silent CF disk strikes me as an ideal bedroom computer; : you can leave it on all the time and just let the screen sleep when you're : not using it. The ideal bedroom computer wouldn't have a monitor either because that makes a lot of noise. The I-Opener looks very promising here, but only if you have one of the cheap units. I'd hate to buy one now at full price given how hard they are to hack. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
In message [EMAIL PROTECTED] Taavi Talvik writes: : On Thu, 28 Dec 2000, Bill Fumerola wrote: : : If your company's infrastrucutre changes are made in a way that if : the project adopted them it would help binary support, I'm sure that would : be accepted. : : ie. if we just made function foo() more generic and then you could : simply provide a KLD, that would make everyones life easier. : : Still, I personally believe, that "core" or general "freebsd community" : should explicitly state, that support for binary drivers and support for : easier inclusion of binary driver or just third party driver is eagerly : encouraged. And as much as possible, easy inclusion of binary drivers : sould be kept in mind whether makeing changes to /usr/src/Makefile or : kernel interfaces or even discussions on the freebsd lists. Core has stated in the past a strong desire for developers not to break kernel interfaces within minor releases. : Why we do not take similiar position on binary drivers - they just : work, and freebsd community just encourages this? That certainly is the goal. Sometimes we achieve the goal, other times we fall short. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
In message [EMAIL PROTECTED] Dennis writes: : 4.1 broke that "policy" rather badly. Perhaps its time to get rid of the : mbuf macros, as any change to that structure breaks binary compatibility in : the worst way possible. Agreed. There are too many things that have been MFC'd that change the interface and too little oversight of them. FreeBSD is better about not breaking things than many others, but we're far from perfect. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
In message [EMAIL PROTECTED] Wes Peters writes: : What's a good price point for a bedroom/kitchen "thin" computer with an : 800x600 LCD panel? If it had builtin ethernet, then I'd go up to $400-$500. If not, then I'd go $50-$100 less. Especially if there were no slots at all in it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Easy way to recover disk
OK. I have a disk drive that is failing in random ways. Today blocks 123 456 and 293 might be unreadable. Tomorrow, it might be these and 27 or it might just be 27. It is an IDE drive. I was wondering if anybody had a program that would read the entire disk and keep a list/bitmap of the bad blocks and try them again next time the program is run. Operating on a slice or partition level would be ideal (I have a 20G disk that is failing, but only about 18G of free space). Ideas? Warner P.S. Basically what I want at the end of the day, disk willing, is what dd if=/dev/ad8s2a of=/huge/big-honkin-file ... would give me. I want this so I can then dump it to tape. I can't run dump directly since it hits those bad blocks and whines. P.P.S. Yes, I know I should have backups. P.P.P.S. Yes, I know that I may be SOL. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Easy way to recover disk
In message [EMAIL PROTECTED] Matthew Jacob writes: : Isn't this what the Linux badblocks program is for? Why don't you take that : and find a way to feed this into badsect(8)... I thought the linux badblocks program found bad blocks and keep the user from using them. I want to read the entire disk and the parts that don't read I want to try again later to see if I can maybe get lucky. The disk has too many bad sectors to really use... So far the brute force approach seems to be going quickly. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Easy way to recover disk
In message [EMAIL PROTECTED] Matthew Jacob writes: : No, badblocks always reads the whole disk- it emits a list of badblocks. : It's e2fsck that is then used to tell the filesystem that these blocks are : unavailable. Ah. Yes. I see now. It would be useful. Before I discovered this I hacked togheter something that seemed to work. It basically read all the blocks that it could and save them to a file and note in an easy to parse format the bad blocks. I only had 3 after the first go round (the 512 byte reads did the bulk of the trick, 8k reads died a horrible death, fsck couldn't cope). I don't know why 512 byte reads did it, and I noticed my simple progress meter ran faster or slower depending on which part of the disk it was on. Also, PIO mode seemed to be better at reading the blocks. I turned the drive off and let it set for a few hours and was able to recover the last 3 blocks at that time by hand. Interestingly enough, once I was able to read an entire partition with 512 byte reads, mount, fsck and some light disk activity seemed to work with the 8k and 16k read/writes that implied. This is a stupid 20G toshiba laptop disk that I wouldn't have thought did bad block remapping. So I'm now running dump on the resulting file :-) The only thing I couldn't figure out how to do was to mount the file. Since I grabbed the disk partition, I wasn't sure I could just use vnconfig since there was no FreeBSD label on that partition. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Just how standard is APM?
In message [EMAIL PROTECTED] Graham Wheeler writes: : Hi all : : I'm running FreeBSD 4.2-S on a Compaq Presario laptop. This laptop seems : to have APM support (at least it does under MS-Windows), but FreeBSD : doesn't recognise it as such. I've gone so far as to add additional log : messages in the kernel probes for the APM BIOS, and these log that the : initial vm86 BIOS call to get the APM BIOS version fail. : : Is this really exceptional, or are there lots of unsupported APM BIOSes? : I believe that APM is a WinTel `standard'; just how standard is it : really? APM is standard. Except when it is broken in some brain damaged ways. However, you likely have your apm device disabled in your kernel and all you need to do is enable it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Allocating an IRQ on PCI
In message [EMAIL PROTECTED] "Matthew C. Forman" writes: : Thing is, here the BIOS hasn't allocated an IRQ, so I'll need to : bus_set_resource in my probe to get one. To complicate matters, the : device's interrupt generator is pretty flexible, and can generate an : interrupt on (almost) any IRQ line. I have to tell it which IRQ to use : when I know which one has been allocated. No. You don't want to use bus_set_resource() since it won't do what you want. What version of FreeBSD are you failing with? Newer versions of current just do the right thing. Otherwise you will have to turn plug and play OFF. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Just how standard is APM?
In message [EMAIL PROTECTED] Graham Wheeler writes: : Nope - as I said, I added log messages to apm.c to log the BIOS probe : and they log a failure (I have "device apm0" in my config file). What's the failure mode? Is it enabled in the BIOS (I assume it is, otherwise it wouldn't work in 'Doz). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Xbox
In message [EMAIL PROTECTED] Mohan Khurana writes: : Well, this is going to seem like a rather strange question. I understand : that Xbox is simply IA-32, however I have heard that the Xbox has a : special ROM that boots Windows CE, to ensure that people do not purchase : the Xbox for the sole reason of running FreeBSD or any other operating : system on it. Does anyone know enough about Xbox internals to verify that : FreeBSD will or will not be able to run on Xbox without any type of : hardware modification? I know that NetBSD/hpcmips uses Windows CE as a boot loader. It will be harder on the Xbox, since Windows CE 3.0 breaks many of the interfaces that pbsdboot.exe used. Don't know if that was on purpose, or if it was accidental to cleaning up the horrible protection mechanisms that were in place before. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting default hostname to localhost
In message [EMAIL PROTECTED] Robert Watson writes: : Unless there are some really good reasons : not to (which there may be), I'd like to commit changes to -CURRENT's : /etc/default/rc.conf to change the default hostname to "localhost". We have localhost.com as one of our domains here in the Village. So long as this change doesn't generate traffic to us in any way, shape, or form, I'd say go for it. Sniff your network for traffic to/from 204.144.255.150 to see if it does or not. There have been bugs in the past that would cause this to be the case. There have also been bugs in the past where machines (not necessarily FreeBSD machines) whose hostname was foo.com (for all values of foo) would try to use localhost.com as the loopback address. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting default hostname to localhost
In message [EMAIL PROTECTED] Archie Cobbs writes: : There is an RFC that specifies a "private use" top level domain, : analogous to 192.168.0.0/16, 10.0.0.0/8, etc. : : The domain is ".local" so any default ending in ".local" should : not conflict. RFC 2606 states: To safely satisfy these needs, four domain names are reserved as listed and described below. .test .example .invalid .localhost ".test" is recommended for use in testing of current or new DNS related code. ".example" is recommended for use in documentation or as examples. ".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid. The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use. But RFC 2964 and 2965 (which relate to http things) both say The IESG notes that this mechanism makes use of the .local top-level domain (TLD) internally when handling host names that don't contain any dots, and that this mechanism might not work in the expected way should an actual .local TLD ever be registered. So it looks like the more porper choice is 'host.invalid' rather than 'localhost'. I think that would, in the end, cause fewer problems. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pppd mkdir diff
In message [EMAIL PROTECTED] "W.H.Scholten" writes:
: + while (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1 ] = 0;
Style(9) says write this like:
while (path[ strlen(path)-1 ] == '/')
path[ strlen(path)-1 ] = 0;
: +
: + slash = strrchr(path, '/');
: + if (slash) {
: + *slash = 0;
this is not an integer, but rather a character. *slash = '\0'; please.
: + while (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1 ] = 0;
Ditto.
But why do this at all?
'mkdir /a/b/d/e' is required by posix to create /a/b/d/e if /a/b/d
exists.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: bus_alloc_resource and RF_SHARABLE
In message [EMAIL PROTECTED] "Justin T. Gibbs" writes: : RF_SHARABLE requests to share a resource with another device, not : within the same device. Further, RF_SHARABLE only applies to : IRQs, not BARs. Actaully, the underlying RF_SHARABLE is for any region of resource that can be multiplexed between different devices. However, in practice, only IRQs can be shared. And even then the device drive would only be working around bugs in the bridge drivers that don't enable sharing. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sys/disklabel.h in C++ files
In message [EMAIL PROTECTED] Alexander Langer writes: : How do you include sys/disklabel.h in C++ files? You can't. It is broken :-(. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sys/disklabel.h in C++ files
Warner Losh writes: : In message [EMAIL PROTECTED] Alexander : Langer writes: : : How do you include sys/disklabel.h in C++ files? : : You can't. It is broken :-(. But I just fixed it. Looks like version 1.54 broke this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sys/disklabel.h in C++ files
In message [EMAIL PROTECTED] Wes Peters writes: : Warner Losh wrote: : : In message [EMAIL PROTECTED] Alexander : Langer writes: : : How do you include sys/disklabel.h in C++ files? : : You can't. It is broken :-(. : : Alexande, you could fix it, and submit it in a PR. : : Hope springs eternal. No need for Hope to Spring. As near as I can tell, I've fixed it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
