Re: kern/99979: Get Ready for Kernel Module in C++
It's less ugly than it used to be, esp. with the bus_read_X() stuff. There's no separate bus_alloc_resource/bus_setup_intr for interrupts though for example, just bus_setup_intr() equivalent. This is pretty simple though: /* OS X */ IOMemoryMap *myBarMap; void *myBar; u_int32_t reg; /* BAR 0 */ myBarMap = provider-mapDeviceMemoryWithRegister(kIOPCIConfigBaseAddress0); myBar = myBarMap-getVirtualAddress(); reg = OSReadLittleInt32(myBar, FOO_REG); reg |= BAR_FLAG; OSWriteLittleIntew(myBar, FOO_REG, reg); myBar-release(); In FreeBSD-7 this is something like: struct resource *res; int rid; u_int32_t reg; uint32_t is the standards compliant spelling :-) rid = PCIR_BAR(0); res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, rid, RF_ACTIVE); The above should be shortenable to: res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, PCIR_BAR(0), RF_ACTIVE); because we don't need to have rid be a pointer. /* XXX: Not sure about endian.. stream_read maybe? */ no. bus_read is correct, because the pci bus is little endian by definition. bus_stream_read will read/write from native endian to bus endian. reg = bus_read_4(res, FOO_REG); reg |= BAR_FLAG; bus_write_4(res, FOO_REG, reg); bus_release_resource(dev, SYS_RES_MEMORY, rid, res); We should be able to shorten that to: bus_release_resource(dev, res); these days. Which is very similar though there is some clutter (bus_release_resource() should take fewer args, like just dev and res, and it would be nice to say something like map_bar(dev, PCIR_BAR(0)) and get back a resource *). Agreed. If you have mutliple resources, you can stack them up as well. Usually drivers come up with macros to hide the bus handles and tags which is an indication that they were quite unsightly (thankfully that's been fixed in 7). :) I usually do: #define RD4(sc, r) bus_read_4(sc-res, (r)) #define WR4(sc, r, v) bus_write_4(sc-res, (r), (v)) which makes usage even shorter. It also helps me hid cross-version differences... Anyways, if you took FreeBSD-7 and cut down some of the gunk similar to OS X you'd have something like: struct resource *res; u_int32_t reg; res = pci_alloc_bar(dev, PCIR_BAR(0)); /* XXX: endian question again */ reg = bus_read_4(res, FOO_REG); reg |= BAR_FLAG; bus_write_4(res, FOO_REG, reg); bus_release_resource(dev, res); Which is at least somewhat better I think. In the case where you don't care what kind of mapping you get, that would work great. It wouldn't be too hard to implement a pci_alloc_bar that does the default allocation and mapping. Changing some of the other APIs would be more difficult... Also, in FreeBSD, the resources are already allocated by the bus code. It just changes ownership to the child when the request comes in... Yes, this has been a recent improvement. Yes. We also do it in a lazy way so that if the resource is allocated or not is transparent to the driver and the system. If it could be decoded, we reserve it. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Get pid of child that has exited?
How does one get the pid if a child process that has exited? On other systems this is available in siginfo_t but si_pid seems to be 0. Is that normal? wait4, wait3 and waitpid will all return it: If wait4(), wait3(), or waitpid() returns due to a stopped, continued, or terminated child process, the process ID of the child is returned to the calling process. If there are no children not previously awaited, -1 is returned with errno set to ECHILD. Otherwise, if WNOHANG is specified and there are no stopped, continued or exited children, 0 is returned. If an error is detected or a caught signal aborts the call, a value of -1 is returned and errno is set to indicate the error. I don't know if si_pid == 0 is normal. I rarely use SIGCHILD to get the status of a child process. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] enhance powerd(8) to handle max temperature
From: Nate Lawson [EMAIL PROTECTED] Subject: Re: [patch] enhance powerd(8) to handle max temperature Date: Thu, 02 Aug 2007 10:08:33 -0700 M. Warner Losh wrote: In message: [EMAIL PROTECTED] Nate Lawson [EMAIL PROTECTED] writes: : Hajimu UMEMOTO wrote: : On Mon, 30 Jul 2007 23:31:33 +0200 : Pietro Cerutti [EMAIL PROTECTED] said: : gahr My patch is really just a first draft that I wrote in order to have : gahr feedbacks on the general idea to implement a temperature controlling : gahr system inside powerd, and doesn't implement hysteresis as you noted, and : gahr your feedback is that it's not a good idea, which I respect. : : It is rather backward, IMHO. I did implement a passive cooling : feature as an enhancement of powerd(8) like you did, during initial : phases. Then, I implemented it in our kernel as a result. : : I'll take a look at your patch. Umemoto-san is right in that you really : want the kernel to control cooling. What happens if powerd dies/hangs : and your system burns up? Passive cooling is often a last resort to : keep the system from overheating. I keep getting the system shutting down on my HP by FreeBSD because the temperature exceeds the _CRT value. Maybe there's something wrong with my values, since it happens a lot: hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 0.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 90.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 94.0C hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 Note: temperature is always 0.0C. What can I do to help my situation, if I really want the kernel doing the cooling? Your embedded controller is timing out. Thus you're getting a bogus value for _TMP. Those settings for _CRT appear correct. It's the measured temperature that is wrong. So how do I track down the problem? I'm tired of the system just shutting down when I'm building OOO or even something simpler like doing a buildworld... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Video memory as swap under FreeBSD
From: Kevin - Your.Org [EMAIL PROTECTED] Subject: Re: Video memory as swap under FreeBSD Date: Fri, 12 Oct 2007 11:54:23 -0500 On Oct 12, 2007, at 11:07 AM, Stefan Esser wrote: Vladimir Terziev schrieb: You're right, the swap, typically configured, is much more than the amount of the video memory, but in fact the swap is just a reserv, which ensures continuation of the normal operations on the machine, at times of peak loads. In our days the amount of RAM placed in the servers is so much, that the swap, in fact, is rarely used at all and a very small amount of it (several MB) is used. In that cases having a very fast swap space in the Video RAM, in addition to the disk swap, would be a good solution. If you have a video card with so much excess memory, that you can use it for swap, then I wonder whether the video card has not been much too expensive ;-) How about spending $25 for another Gigabyte of RAM (real RAM, not SWAP) instead? I'm not commenting on if this is a good idea or not either way, but at least one vendor of servers that we've been buying from is now including 128 or 256MB of video ram(not UMA, real video ram) embedded on the motherboard now. I thought it was odd too, until I asked our sales rep. The 8MB ATI chipset they used to use would have disqualified them from being Vista Capable. So, whether we want it or not, we're getting at least 128MB of video memory on our servers now. I'd thought about trying to use it for something, but decided it wasn't worth the effort. :) It would be a cool hack. it would also be cool technology to have around because to 'swap' to the video ram, you need to have a way to map it to a device. And if you have that, then you have a short delta to many of the pci based battery backed ram disks. I'm sure that writing a small geom driver to cope wouldn't be very hard to do. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Microsoft performance (was: ...)
In message [EMAIL PROTECTED] Matthew Hunt writes: : Security holes are rarely in the kernel, and you can easily keep your : applications up-to-date without rebooting. And the ones that re in the kernel tend to be DoS type problems that force a reboot anyway :-( Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
restricted kernel threads implementation from NetBSD via newconfig
I'd like to bring a kernel thread implementation, ported from NetBDS by the newconfig project, into the kernel. Who would like to review things before they go into the tree? I can see many benefits for having this in the tree, but very little downside. This should allow people to more easily port raid-frame from NetBSD if they desire. FYI, this is an outshoot of the porting of the newconfig code to new-bus. Each bridge controller has its own even thread to handle cards events in a sane manner. It is basically a stripped down pccardd in the kernel, but one that has a huge hint database. I'm not proposing, at this time, to bring it on. I just want to get the kthread stuff in as a separate issue. Comments? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard problems
In message [EMAIL PROTECTED] Greg Lehey writes: : Is that what you meant? No. You need to set machdep.pccard.pcic_irq to be zero in your boot loader. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UMAX scsi scanner on adaptec 1542 Card
In message [EMAIL PROTECTED] Greg Skafte writes: : since this is the only device on the aha card experimental aha drivers : are welcome . (remember though that the target is RELENG_3 not current) OK. I'll make sure that justin's changes are included in the -stable driver and if not send you off a patch to try. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting LILO to FreeBSD
In message [EMAIL PROTECTED] Graham Wheeler writes: : The only reason I even want to do this is that I still have a number : of old DOS games that won't work under Win95. And dosemu and Wine : just don't cut it either, unfortunately. I have a friend that wants to boot FreeBSD on his IDE drive, or Win95 on his SCSI drive. No, it isn't an option to swap them, so the SCSI drive winds up being 'D'. The only way he can boot Win95 is to completely disable the IDE drive from the BIOS' point of view :-(. Would osbs solve this problem, or would he have to take a look at LILO? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting LILO to FreeBSD
In message [EMAIL PROTECTED] Adrian Filipi-Martin writes: : The standard boot partition selection softwre also works fine : booting windoze OS's from other disks. All you need to do is set the "disk : id" in the DOS MBR to the correct number, 0x81 for your second disk. That's : the only thing that MS doesn't do correctly whe installing the OS on the : non-primary disk. I used to do this a long time ago to boot FreeBSD of the : "C" drive and the other stuff off of "second C" drive. How does one do that? What tools do you use? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: The busspace modernization initiative.
In message [EMAIL PROTECTED] Doug Rabson
writes:
: I think you are on the right lines here. Where does the resource come
: from? Are you going to support bus_space_map() and if so, how are you
: planning to call BUS_ALLOC_RESOURCE?
In i386/i386/resource.c :-). Here's what is there now. It looks like
it currently bypasses BUS_ALLOC_RESOURCE, going to the resource
manager (rman) directly. Do you have any comments on this code? Or
would you rather I send you a complete patch/diff to comment on?
int
bus_space_alloc(t, rstart, rend, size, alignment, boundary, flags,
bpap, bshp)
bus_space_tag_t t;
bus_addr_t rstart, rend;
bus_size_t size, alignment, boundary;
int flags;
bus_addr_t *bpap;
bus_space_handle_t *bshp;
{
struct resource *rv;
struct rman *ex;
unsigned long bpa;
int error;
/*
* Pick the appropriate resource.
*/
if (t == I386_BUS_SPACE_IO) {
if (flags BUS_SPACE_MAP_LINEAR)
return EOPNOTSUPP;
ex = ioport_rman;
} else if (t == I386_BUS_SPACE_MEM)
ex = iomem_rman;
else
panic("bus_space_alloc: bad bus space tag");
/*
* Sanity check the allocation against the resource's boundaries.
*/
if (rstart ex-rm_start || rend ex-rm_end)
panic("bus_space_alloc: bad region start/end");
/*
* Do the requested allocation.
*/
retry:
/*
printf("bus_space_alloc %lx,%lx,%lx,%lx\n",
(u_long)rstart, (u_long)rend, (u_long)size, (u_long)alignment);
*/
rv = rman_reserve_resource(ex, rstart, rend, size, flags, NULL); /* XXX NULL? */
if (!rv) {
return EAGAIN;
}
if ( rv-r_start != EXTENT_ALIGN (rv-r_start, alignment, 0) ) {
rstart = EXTENT_ALIGN (rv-r_start, alignment, 0);
rman_release_resource (rv);
goto retry;
}
bpa = rv-r_start;
rman_activate_resource (rv);
/*
* For I/O space, that's all she wrote.
*/
if (t == I386_BUS_SPACE_IO) {
bshp-addr = *bpap = bpa;
bshp-resource = rv;
return 0;
}
/*
* For memory space, map the bus physical address to
* a kernel virtual address.
*/
if (bpa = ISA_HOLE_START
(bpa + size) = ISA_HOLE_START + ISA_HOLE_LENGTH) { /* ISA hole */
bshp-addr = (u_int)ISA_HOLE_VADDR(bpa);
} else { /* General */
if((error = i386_mem_alloc_and_map (bpa, size, (vm_offset_t*)(bshp-addr {
rman_release_resource (rv);
return 1;
}
}
*bpap = bpa;
bshp-resource = rv;
return 0;
}
: I assume that you will update the alpha version of bus.h too.
Of course.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
In message [EMAIL PROTECTED] Bill Fumerola writes: : It also clears up the misconception that being a member of -core requires : a beard. If it did, then Jordan would be out. :-) Justin too. Those are the only two core members that I can even recall what they looked like... I don't think I've ever seen a 5 O'clock shadow on Justin... Certainly not on a regular basis. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
In message [EMAIL PROTECTED] Wes Peters writes: : 40.1, -105.3, "gibbs, wosh" # Boulder, CO (wow!) wosh? Didn't know there was a wosh in core. It certainly isn't me, since I'm in Boulder, but not in core. There appears to be no wosh account on freefall. : 40.1-105.3 " , merry, passe" # Boulder, CO (wow!) Warner Losh, Ken Merry, Steve Passe and (until recently) Sean Kelly. Boulder is a small town, since I used to work with Ken, Sean and Justin. I now work with Steve Passe : largest concentration so far is Boulder Colorado with 4, followed by Yes. And if those are the only committers, their places of employment are separated by only a few blocks (literally walking distance, I've made the walk before when I was at Pluto since my wife works across the street from Timing Solutions) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
In message Pine.GSO.3.95q.990705091442.676N-10@elect8 Nick Hibma writes: : For your information : http://www.mapblast.com : specifies LongLat at the bottom of the page when you are looking at a : map. Just move the icon to the right place. That puts my current employer at 40.029322, -105.227900 and Pluto at 40.023712, -105.225382. Well, I'd have to knock a couple of significant figures off those since the addresses for these two places don't quite match the icon on the map... I told you they were walking distance... :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD for mips
In message [EMAIL PROTECTED] Doug writes: : I'd just like to offer a hearty hi-ho for a MIPS version of : freebsd. I'd love to be able to put some of these !*#@$* Cobalt Raqs we : have round here to a wholesome purpose. :) Of course doing the install : would be a lot of fun with no floppy disk If nothing else, a program that wrote a custom kernel into / of the current Linux partition might be one way of getting bootstrapped on these machines. :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] Sheldon Hearn writes: : If you do end up messing with inetd's existing ident service, please : make sure that the default behaviour remains the same and that the : operator must do something to enable an ident service that reports more : than just "UNKNOWN-ERROR". Yes. I'd love to replace my perl script: #!/usr/local/bin/perl ($a, $b) = split(/[,\n\r ]+/,); print "$a , $b : USERID : UNIX : Warm-Fuzzy\r\n"; with something a little less heavy-weight. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
: I don't see a point to that. Some ftpd and sendmail servers make the queries. When I have my fake identd in place, they go much faster... :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] Ben Rosengart writes: : I used to run a public shell machine, and one of my users cracked : someone else's site. Identd made it much easier to figure out who the : problem user was. Unfortunately, I've seen the dark side of identd which makes me *HATE* it with a passion. There have been several places that I worked that ran identd, but from which I never sent mail from. The spammers started hitting me there They got the address from the ident replies From this, I'm *NEVER* going to run a identd that gives out real names Hence "Warm-Fuzzy" in my fake script. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] Chris Costello writes: :The whole point of ident was -- and still is -- to : authenticate or verify who created a specific TCP connection. NO. The IDENT protocol was never intended to authenticate who was on the other end. *NEVER*. People ABUSED it as such, but its value is only as good as the person providing the information. : If : the machine is untouched (i.e., has not had the root account : compromised), then ident responses are usually trustworthy : enough. It is generally not applicable to single user operating : systems like Windows, Mac OS, or DOS. FALSE. If I can hit the remote side faster than the machine that is untouched with a response (by sniffing the packets on a network and heavily loading the machine that I'm attacking from, but haven't penetrated root), then the information is bogus as well. At best, the information provides who might be on the other end of the end of the link... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCCARD and Vpp voltage
In message [EMAIL PROTECTED] Bill Paul writes: : - Why is the vpp voltage alwats left at 0? I think that is what the standard suggested. Since I've not yet recieved the standard, I can't look it up. : - Is it safe for me to change the code so that it's set to 5 volts? : Obviously I'm going to need this change in order to make the Aironet : PCMCIA cards work. : - If it's not safe to default vpp to 5 volts, is there a safe way to : detect when it needs to be turned on and do it only for those cards : that need it? I'm not sure. There are low voltage cards and I'm not sure how they would like having 5V applied to Vpp to them. Again, I've not looked up the standards Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] Chris Costello writes: :I was only specifying what I gathered from the RFC. What was : ident actually intended for, then? It was at best a way to track back malicious connections for log files after the fact. Only after the initial standard came out did people try to abuse it for authentication... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : Good idea. I'll have it check to see that it's a regular file. Make sure that you do this with the stat, open, fstat interlocking so that there isn't a race here. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] John Polstra writes: : Really?? Even though their connect() call failed? Ick! I know : sendmail doesn't behave that way. I'll take your word about the IRC : daemons -- I don't know anything about them. Yes. At least that's what I've observed. However, I believe the culprit was a firewall that just dropped the packets for the connection request, so it had to wait 30 seconds to timeout. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : I have this fixed in my latest code (on freefall of course). I did not : use an original stat because that's pointless, as it adds another race : condition. The only downside to my approach is that if it's a symlink : to a dev, the dev can get opened/closed, and d_open/d_close be called. How does the original stat add a race condition. You stat the file, open it, then fstat it. If the two match you know you're good. If they don't, you can detect that something bad has happened Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCCARD and Vpp voltage
In message [EMAIL PROTECTED] Wes Peters writes: : Didn't my message from yesterday make it to the list? On card insert, : you're supposed to read the voltage requirements for Vcc and apply *that* : voltage to Vcc, Vpp1, and Vpp2. If it did, I missed it... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : Ahh, I misunderstood you. In _this_ case you just proposed, the stat is : really pointless. What good would it do? It would let you know if you should even try to open the file... But that doesn't solve the race. The fstat tells you if what you opened was what you thought you were opening... However, for this, the original stat might not be completely necessary unless you were trying to specifically detect someone trying to race you. You are right that it won't buy you anything. I was confusing this with the tree walking case. The stat + fstat check there was needed... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCCARD and Vpp voltage
In message [EMAIL PROTECTED] Wes Peters writes: : From this, I'd say the card inserted event should read the Vcc wanted : value (from the Socket Present State Register?) and apply THAT voltage : to Vcc, Vpp1, and Vpp2, rather than just applying 5.0 volts. You might : seriously damage any 3.3v card inserted by applying 5v to it. Agreed on GPs. I don't think any laptops today have the low voltage slot, but instead have the unified slot. I believe that I saw in there that cards needed to be able to handle 5V as well, but in the world of PC Cards it is much better to be safe than sorry For the moment, the 0 - 50 change is good, but longer term we may need to do the 3.3V stuff correctly. BTW, does anybody know where I can get a type II CF slot to Type II PC Card card adapter? This is so I can plug a pc card into a CF slot (I have one that does the other way round, but want to compare the price of the adapter with the price of a ne2000 CF ethernet card I'm looking at ($130)). : This is a pretty good book, by the way. ISBN 0-201-40997-6. Agreed. That's where I got my ideas about PCCARD as well, since the promised standard hasn't appeared on my doorstep yet. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: keymapping continued ...
In message [EMAIL PROTECTED] The Hermit Hacker writes: : I need to build a keyboard map such that: : : F1 == ESC OP : F2 == ESC OQ : Shift-F1 == ESC [31~ : Shift-F2 == ESC [32~ Why not do this with Xterm translations? Generally speaking xmodmap and friends are poor choices to even think about doing this with since they don't translate function keys to escape sequences. The applications do that, if they want. The only time you're likely to need them is in a terminal emulation situation, which makes xterm the logical place to do this. : Hopefully this makes a bit more sense? Yes. It does. You should use the translations resource for XTerm to accomplish this. From my .Xdefaults file: XTerm*vt100*translations: #override \n\ Alt KeyPress y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\ Meta KeyPress y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\ KeyPress BackSpace: string( 0x7f )\n is one example. It allows me to "map" the BackSpace key into a DEL character (which in my religion is the right thing to do, your religion might vary), as well as giving me an easy way to paste, at least into xterms when I don't have a middle mouse button. This could easily be expanded to include all the vt220 keys that your boss/coworker needs in xterm. Check out the xterm man page for a more complete example, including ways of mapping different keymaps at the touch of a key. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
In message [EMAIL PROTECTED] "David O'Brien" writes: : Since no one has repsonded to this querry, I will be un-staticizing these : so they will be available to drivers. No. Please don't. This is the first I've seen this. There will be another cis reading interface as part of the newbusification of pccard stuff and I'd rather not have to fix any more drivers than I have to. I wish I had seen it sooner. The Xircom driver is one of the ones that my first attempt at newbusification would have broken... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
In message [EMAIL PROTECTED] Scott Mitchell writes: : Ugh. In that case, can someone back out Poul-Henning's changes to the : if_xe.c in the -STABLE tree? That's (I hope) the only thing stopping it : from working. At least that way only my code will be bogus :-) Believe : me, I know it's ugly, but there's no getting around the fact that the : driver needs to read the CIS, and right now there's no clean way to do that : in -STABLE (is there?). Can I get your comments on the following interface? int pccard_map_cis(int slot) Maps the slot's cis into memory. You must call the before any of the following. It returns 0 on success, or an error from /usr/include/sys/errno.h (most likely EBUSY if there are no memory windows available). int pccard_unmap_cis(int slot) Unmaps the CIS. This frees any resource used by the slot to map its CIS. It returns 0 on success, and an errno value if not. vaddr_t pccard_cis_addr(int slot) Return the virtual address of the CIS. The CIS must be mapped before call this function. Drivers may read/write this memory. Reading this memory will get the CIS entries. Drivers are responsible for interpreting the CIS. Writing to CIS locations generally is used to configure the card and does not change the CIS stored on the card. If the card is not mapped, then 0 will be returned. It is not valid to access memory returned by this call after a call to pccard_unmap_cis. Future interfaces may ease the burdon on driver writers, but this interface will be supported for a while. Does this fill your needs? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changing argv[0] after fork()
In message [EMAIL PROTECTED] Wayne Cuddy writes: : Even though I am developing on FBSD is there a "more portable" way to do this? No. Well, not short of execing. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
In message [EMAIL PROTECTED] Mike Smith writes: : if (strlen(buf) = sizeof(buf)) : return(error); This can never be true with the strl functions They don't run off the end, so strlen(buf) is always going to be sizeof(buf) since it doesn't include the traling null. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
In message [EMAIL PROTECTED] Mike Smith writes: : What's really stupid is that most of the time you're trying to use : these functions to fix code that looks like: : strcpy(buf, str1); : strcat(buf, str2); : strcat(buf, str3); : without overflowing buf. This is dumb! Use asprintf instead: : : asprinf(buf, "%s%s%s", str1, str2, str3); : : If you can't keep all of the string elements together at once, try: : : asprinf(buf, "%s%s", str1, str2); : ... : asprintf(buf2, "%s%s", buf, str3); : free(buf); : : No, it's not fast, but it _is_ robust. That is true for this case, but not always true. I think these APIs have an excellent role to play. Sure, there are other ways to do it, but there are a growing number of systems that have strl* on them (OpenBSD, Linux and Solaris), which is reason enough to improve our portability by using them. The asprintf isn't completely robust becuase you must free() the routine, or face a memory leak. It won't overflow, but it might introduce another bug. The whole point of these APIs was to transition old code to new in a safe manner that isn't prone to potentiall programming errors. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
In message [EMAIL PROTECTED] Mike Smith writes: : Ugh. Take the first example in the paper; it rewrites as : : len = asprintf(path, "%s/.foorc"); : : as opposed to : : strlcat(path, homedir, sizeof(path)); : strlcat(path, "/", sizeof(path)); : strlcat(path, ".foord", sizeof(path)); : len = strlen(path); : : Yes, they're a better str*cat/cpy, but they're not the solution that : they claim to be. You've forgotten the free(path) sometime later in your code... That's a can of warms you conveniently ignore... And can be big problems for library routines whose API is defined to return stuff into a static buffer... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
In message 19990715194203.A54146@mad Tim Vanderhoek writes: : Looking at OpenBSD's actual definition of strlcat() which returns the : number of chars that would have been in the final string is : potentially non-useful, but not really too terrible. No. It is useful. If you look at the return value, you can detect that an overflow would have happened and bail w/o having the overflow actually happen. That is useful (and even documented in the man page by a nice example). : given the opportunity to submit a replacement manpage, since theirs : sucks. : : Bah. You're in avail now. Just commit ontop of whatever manpage gets : imported. ;-) If your replacement is good, no one will object. :) I'm planning on committing their man page. I don't see problems with it, purhaps people could point them out to me so that both our man pages and theirs could be better. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
In message [EMAIL PROTECTED] Mike Smith writes: : I still think this is the wrong way to deal with the problem. 8) We mildly disagree here. The strl* functions are the end all, be all of security. They are just designed to make the existing code that uses static buffers easy to make more robust w/o radically altering that code. Of course, strings have always been weak in 'C'. You make them static and they overflow. You malloc them, and often people forget to free them later leading to other problems... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
In message [EMAIL PROTECTED] Warner Losh writes: : We mildly disagree here. The strl* functions are the end all, be all : of security. NOTE: This should have read: We mildly disagree here. The strl* functions are NOT the end all, be all of security. which changes its meaning quite a bit... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
In message [EMAIL PROTECTED] Sheldon Hearn writes: : If you see my point, let me know and I'll send you an alternative : strlcpy.3 . I can see your point. I don't know if I'll like your man pages better or not, but I'd be willing to give them a spin. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: telnetd
In message [EMAIL PROTECTED] Peter Jeremy writes: : There's nothing stopping you unifdefing telnetd on your system. I : have no opinion as to the merits (or otherwise) of leaving the : ifdef's in the main code tree. True, but since some of what I'm doing is making sure that there are no security implications to some of the paths, doing that would be useless, since that wouldn't be what is checked into the system. We really don't need the ifdefs for solaris, cray, etc, do we? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
(most of it are due to lack of a real getopt routine). FreeBSD does have a real, 100% posix compatible getopt. Maybe you are missing one of the numerous, non-standard Linux extentions? Gnu's getopt can be found in about a dozen different places in the FreeBSD tree. cvs, tar, etc. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
In message [EMAIL PROTECTED] Per Lundberg writes: : I know it isn't standard. But it works well, and is used by a lot of : programs. Perhaps it should have been put in another library than libc, : though. Actually, I'd better suggest this to the GNU people right ahead. There has been talking of having a libgnu.a to contain common routines like the long getopt... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
In message [EMAIL PROTECTED] Chris Costello writes: : getopt other than --foo-bar flags that everyone I know hates? Not everyone hates them... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sv: speed of file(1)
Maybe the P60 is memory starved. Thrashing would cause this huge factor of speed difference... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAO
In message [EMAIL PROTECTED] Geoffrey Robinson writes: : pccardc: /dev/card0: Device not configured Rebuild your kernel with pccard support. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [FreeBSD-net-jp 1746] [FYI] Adaptec AIC-6915 Starfire ethernet controller driver and plus question compaq presario dec et
[[ Warning, you'll need something which can display Kanji to be able to read what I've written. I'm using mule and netscape. I've tried to make the non-Japanese parts separate enough that if you only understand English and have only english viewing programs, you can safely ignore the strange sequences of characters resembling TECO progragms and/or line noise. ]] In message [EMAIL PROTECTED] Bill Paul writes: : Sorry, but I'm just a dumb american: I can't read this. $B?=$7Lu$4$6$$$^$9!#;d$OJF9q?M$G$9!#FI$_$^$;$s!#(B (which translates, if I've gotten the Japanese correct, as "I'm very sorry. I'm an american. I cannot read this.") $B%3%s%Q%C%/!!(BPRESARIO$B!!(B2274$B!!$K(BFreeBSD3.2$B%$%s%9%H!%k$7$?$N$G$9$,!"(B NIC$B!'!!(BDEC 21143-based $B$H%S%G%*%+!%I!'(BSiS5598$B$N@_Dj$,$$^$/$$$-$^$;$s!"8=:_(B $BF0$+$7$F$k(B $BJ}$,$$$i$7$?$i65$($F$/$@$5$$!#(B Using Netscape and http://www.dgs.monash.edu.au/cgi-bin/cgiwrap/jwb/wwwjdic?9T (and my little knowledge of Japanese grammar) I believe that this says something along the lines of: Compaq PRESARIO 2274 with FreeBSD 3.2 installed, but NIC: DEC 21143-based and Video Card: SiS5598 which won't [attach]. In the current [system], can you please instruct me how [to make it work]. The text in [] is guessed based on context, I didn't look up the words in hiragana that I didn't already know, or for which the literal translation didn't make sense. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SURVEY: Sound cards that work under FreeBSD
In message [EMAIL PROTECTED] Dirk GOUDERS writes: : My sound card is a SBPCI128 by Creative Labs. Nice card... I have one too. Plays mp3 well :-). Also plays video sound well and xgalaga works with sound!... NOTE: The SBPC64 doesn't work without an external patch... Be careful. : I only used the card with FreeBSD 3.2 I've used mine on -CURRENT for about 9 months or so, but part of that time I had to get the driver from somewhere else. : The only line I had to add to my kernel config file was: : : device pcm0 at isa? port ? tty irq 10 drq 1 flags 0x0 : : (This causes a message "pcm0 not found" to appear at boot time but : just ignoring it seems to be o.k. - allthough I would prefer : not to see it, at all.) device pcm0 does the trick for me. I think that will work in 3.2. -current fixes the problem with psm0 not found. : I had to build the audio device snd1: : : # cd /dev : # sh MKDEV snd1 When you upgrade to 4.0 or -current, you'll have to undo that stuff... : and to use the mixer to set the volume to another value than 0. : I use the following script /usr/local/etc/rc.d/mixer.sh at boot time: : : #!/bin/sh : /usr/sbin/mixer vol 60:60 pcm 60:60 cd 60:60 Cool. I've always brought up xmixer to do this Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf leakage
In message [EMAIL PROTECTED] "David E. Cross" writes: : Any-who, is there a way I can get a look at the raw mbuf/mbuf-clusters? : I have a feeling that seeing the data in them would speak volumes of : information. Preferably a way to see them without DDB/panic would be ideal. I've also seen problems with amd with huge links on 3.2 Release The whole system hangs until the link is done, then it starts working again. Can't help you with looking at the mbuf stuff, however. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
In message [EMAIL PROTECTED] Chris Costello writes: :Are you going to be listing all the RFCs that apply? For : example, DNS is 1033, 1034, and 1035, and NNTP is 0850 and 0977. DNS is also 1123 and a few others in the 2xxx range. Then again, a lot are 1123 :-) NNTP should just list 977, however, since it obsoletes earlier RFCs. The net news format RFC isn't relevant to /etc/services, much like RFC 822 wouldn't be the one to list for smtp (since it describes the message format, not the protocol for smtp). For smtp, one of the RFCs would be RFC 823. (I just hope that I've not accidentally reversed those two RFCs). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: deny ktrace without read permissions?
In message [EMAIL PROTECTED] Sheldon Hearn writes: : This doesn't look right. If I can execute a binary, I can have the : system allocate memory to me and but the binary image in it. It's my : memory. :-) Also, one can use a custom libc to get around the readonly ness, since functions in libc can access the entire memory space (at least on intel). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SURVEY: Sound cards that work under FreeBSD
In message [EMAIL PROTECTED] Dirk GOUDERS writes: : What I still don't understand is the following message at boot time: : pcm1: using I/O space register mapping at 0xe400 : I am wondering why there is a message concerning pcm1 instead of pcm0... Quirks in config system in -stable cause it to usually attach to pcm1 when it is on the pci bus. It is nothing to worry about, just be aware that things like /dev/mixer, et al, need to point to the 1 unit rather than the 0 unit. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
In message [EMAIL PROTECTED] "David O'Brien" writes: : Before importing, it must display a version number of 1.0 (or drop the : version number). This is not Linux where everything is version 0.xy. For a long time the new boot loader was in the tree with a version 0.xx... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: interesting bug in /usr/bin/cmp
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : if ((p1 = (u_char *)mmap(NULL, : - (size_t)length, PROT_READ, MAP_SHARED, fd1, off1)) == (u_char *)MAP_FAILED) : + (size_t)mlength, PROT_READ, MAP_SHARED, fd1, off1)) == (u_char :*)MAP_FAILED) : err(ERR_EXIT, "%s", file1); This would be a good candiate for different line breaks for clarity if ((p1 = (u_char *)mmap(NULL, (size_t)mlength, PROT_READ, MAP_SHARED, fd1, off1)) == (u_char *)MAP_FAILED) would be more readable and not violate the 80 column rule. Since the call to mmap is already split and you are already changing it, I don't think this would be a problem. While I do try to minimize stylistic changes, I think this one makes good sense : - (size_t)length, PROT_READ, MAP_SHARED, fd2, off2)) == (u_char *)MAP_FAILED) : + (size_t)mlength, PROT_READ, MAP_SHARED, fd2, off2)) == (u_char :*)MAP_FAILED) : err(ERR_EXIT, "%s", file2); See above :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message [EMAIL PROTECTED] "Jordan K. Hubbard" writes: : It already is. That's not the question under discussion here - we're : talking about how to make things work in the post-installation boot : scenario. I'm in favor of having it in the kernel by default. With one proviso. Any place where we talk about locking down a FreeBSD machine, we'd need to make it explicit that bpf should be turned off when you wish to make it hard for intruders to get packets off your wire in a root compromize situation. I wonder if /dev/bpf should be disabled when secure level is 1 or 2... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : And how about having : if (securelevel 3) : return (EPERM); : in bpf_open()? There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of "raw devices". Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message [EMAIL PROTECTED] Alfred Perlstein writes: : What about the one-way sysctls that have been suggested? They need to be implemente dfirst. A quick securelevel 0 in bpf_open would allow many people's objections to bpf in the kernel by default. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message [EMAIL PROTECTED] "Jordan K. Hubbard" writes: : There are no security levels 3. I'd be happy with 0. This is : consistant with the meaning of "raw devices". : : Would you be willing to make this change? Yes. I will make this change tomorrow unless there is significant objections that cannot be resolved in the mean time. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message [EMAIL PROTECTED] Christopher Masto writes: : I hope you mean " 1". I often diagnose problems using tcpdump etc., : and I don't think bpf should be broken just because someone wants the : minor "flags can't be turned off" feature of level 1. Flags can't be turned off at level 1, and raw devices cannot be accessed: 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted filesystems, /dev/mem, and /dev/kmem may not be opened for writing. Notice that raw devices cannot be opened... : It seems to be that disabling bpf is more appropriate for security : level 2 and up, if such a thing is desirable. I'm not sure it is. 2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with filesystems by unmounting them, but also inhibits running newfs(8) while the system is multi-user. and 3 Network secure mode - same as highly secure mode, plus IP packet filter rules (see ipfw(8) and ipfirewall(4)) cannot be changed and dummynet(4) configuration cannot be adjusted. I could see arguments for both levels Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message [EMAIL PROTECTED] Bernd Walter writes: : There are no security levels 3. I'd be happy with 0. This is : consistant with the meaning of "raw devices". : That would mean you can't run a secured DHCP server :( No. That would mean you'd have to start DHCP before raising the secure level. *THAT* is acceptible, unless restarting the dhcp server is a normal thing to do. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
In message [EMAIL PROTECTED] John-Mark Gurney writes: : I vote for allowing inetd.conf to specify a port number instead of a : service name... it should be very easy to make the modification, and : I'm willing to do all the work, assuming no one on -committers objects.. I'd love to be able to do this. I have a firewall-like machine that I run services on several different that have no real names... I'm hacking /etc/services now, which is just wrong... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposing argv for klds and preloaded modules
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes: : Modules are not just drivers. Forget about drivers, and try again. : :-) But the generic mechanism extends beyond just drivers :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : Allow me to re-quote the message I answered: : : I vote for allowing inetd.conf to specify a port number instead of a : service name... I've said it before, and I'll say it again: This is an excellent idea! Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : Daniel Eischen [EMAIL PROTECTED] writes: : Dag-Erling Smorgrav wrote: : The correct way to do this is to fix getservbyname() so it accepts : port numbers. : Are you sure this is what you want? I'm 100% positive that I want this. : It may allow an application to : use a port number that would otherwise be invalid. I think he's saying that you could run telnet on port 25, which is reserved for mail. I say that I don't care if it allows this. In fact, I want to be able to do things like that... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
In message [EMAIL PROTECTED] Bill Fumerola writes: : Copying the telnet line and changing the first word to 'http' does wonders : for being to access machines from inside a school district's firewall. What if the service has no name? : Choosing ports by number would be nice, however the same objections Matt : had with changing our API ring some buzzers in my head too, however the : evil side of me says "screw whoever is porting inetd, we like functionality. : : The evil side normally wins. I don't think we should change getportbyname. If the getportbyname fails, see if a strtol returns a number, and if so use that. I don't see what is so hard about doing that. If someone wants to run a service on a port that it wasn't desinged for, they can still do it today. I don't see what the argument against this change could possibly be. There is no evil here. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
In message [EMAIL PROTECTED] Darren Reed writes: : Why not just use the changes NetBSD made to their inetd ~6 years ago ? Didn't know about them? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
In message [EMAIL PROTECTED] Brian Somers writes: : Yes, but do it the other way 'round - strtol first, if it's not all : numeric, getservbyname(). I did it getservbyname first in case there were any legacy services that were all numbers. Traditionally, this is hwo things were done with IP addresses, although a quickie survey shows it to be a mixed bag. The biggest reason for not doing getservbyname first is that it will hang (long timeout) if the databsae behind it goes away. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
In message [EMAIL PROTECTED] Brian Somers writes: : Exactly - ditto for gethostbyname(). In the case of gethostbyname(), : I believe that domain names can't have a number as the first : character - I would have thought this idea should follow through with : services. No. That is in error. 3com.com or 2112.com. See RFC 1123 for the loosening of the restriction. You have to parse the whole string to know if it is a valid IP address or not anyway. : I know I'd be pretty annoyed if I tried to do something like ``ssh -p : 1234 somewhere'' after configuring my interface in single-user modem : with nis in /etc/host.conf and found that ssh was looking up 1234 in : /etc/services. Even if this is right, it's not intuitive. But inetd isn't involved here at all. You do bring up a good point here in argument by analogy. However your rule for isdigit(arg[0]) breaks the following services: 3com-tsmux 106/tcp 3com-tsmux 106/udp 914c/g 211/tcp#Texas Instruments 914C/G Terminal 914c/g 211/udp#Texas Instruments 914C/G Terminal 9pfs564/tcp#plan 9 file service 9pfs564/udp#plan 9 file service 3l-l1 1511/tcp 3l-l1 1511/udp 3ds-lm 1538/tcp 3ds-lm 1538/udp 3m-image-lm 1550/tcp#Image Storage license manager 3M Company 3m-image-lm 1550/udp#Image Storage license manager 3M Company at least we know there are no all numeric service names in the standard /etc/services file. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Building a new kernel
In message [EMAIL PROTECTED] Osokin Sergey writes: : try to cvsup your source tree to 4.0, then rebuild your system : with simply make world procedure. I can't do that. This system *MUST* be a 3.2-stable system. I was building the kernel to test to see if a nasty NFS bug I've found in -stable is present in the exact same environment but with a -current kernel rather than a -stable one. I was just noting this for people in the future. It is something that I've tradtionally been able to do and I couldn't do it in this case. Others less worldly surely will hit the problem over time... Likely near the time we release 4.0 if the compiler situation remains the same. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Building a new kernel
In message [EMAIL PROTECTED] David Scheidt writes: : Read the docs? Who me? It sounds like the 3.X to 4.0-RELEASE documentation : should say not to do this. Unless, of course, gcc-2.95 is imported before : t hen. Give me a F*ing break. No such documetation exists and the more that we change in how things traditionally the more problem's we'll have. gcc 2.95 is the same thing as egcs, so that wouldn't matter... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE quirk in 3.2-STABLE kernel ?
In message 001201bedfb8$92fa3440$[EMAIL PROTECTED] "Biju Susmer" writes: : I dont think it should be a problem.. Since other OSs can work with this : configuration without any problem, why FBSD should refuse this configuration? : When i was using 2.2.7-stable, FBSD used to recognize my CDROM *sometimes* as : slave, not always. I've been running hacked drivers here for a long time that always probe both primary and secondary and haven't had problems with that... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE quirk in 3.2-STABLE kernel ?
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : Since it was made to work? The problem here is that this person, for some : reason, is misconfiguring their system and expecting it to work as if it : were configured properly. Odd, all of the machines that I've seen shipped lately have their CDROMs on a secondary IDE controller as SLAVE with no master. Works great, and the FreeBSD drivers work well when hacked to not require a master fo there to be a slave Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs
In message [EMAIL PROTECTED] John Baldwin writes: : Perhapas have a group that has write access to all the archive and stick the : user in that group? That doesn't prevent checkins, however. You can do that inside the respository itself. Just try to do a commit on your local mirror of the FreeBSD respository, for example. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE quirk in 3.2-STABLE kernel ?
In message [EMAIL PROTECTED] Chris writes: : As always when a misconfiguration (read 'not to spec') is used enough : then it quickly becomes somewhat of a de facto standard. I'd love to see chapter and verse on this :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs
In message [EMAIL PROTECTED] Bill Fumerola writes: : cvsup seems to set the wrong attributes after I've forced them to work : that way. I see this when I cvsup as root too (although the file you quoted should be r--r--r--. I can't get the modes on the directories to be 775... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : You can always use off_t with "%qd", (int64_t)foo. But that isn't portbale. %qd is a bsdism. %lld and %llu are the latest C standards way to say that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : Sorry, kinda used to quad rather than long long. I'm pretty sure ll : isn't yet supported by the kernel printf functions... You may be right about that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Parallel Zip Drive on FreeBSD 3.2-RELEASE
In message 11366.934157821@localhost "Jordan K. Hubbard" writes: : I have a parallel port Iomega Zip Drive. I have installed 3.2-RELEASE and : although the vpo0 is detected it does not see da0, and when I try "mount -t : : I'm not surprised, since da0 would be a SCSI device. But vpo0 is a SCSI controller. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes: : Well, Terry does, though I don't quite recall his reasoning. :-) : Notice, he objects the way FreeBSD is today, with the bind resolver : API inside libc. The size of _res has changed. Although it starts with an _, it is officially part of the API. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Disk label recovery - request for suggestions.
In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : superblock (or one of its backup copies), you can determine the offset : and size of the FS. It won't tell you anything about *other* : partitions though. It will give a fairly strong hint, however. If you know what is taken up by this partition, you can remove it from the pool of available space and guess with a relatively high degree of accuracy that the next partition begins where this one ends. :Is this trick possible with other : kinds of file systems too? : : That's totally dependent on the particular file system. For instance, : a swap partition contains no metadata (that I know of), so all you can : do is deduce it's size and position from the sizes and positions of : surrounding partitions, and of the slice they're in. Yes. This is true That's one of the problems of my disklabel reconstruction program that tries to run fast... It slows way down when it hits the swap area... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
In message [EMAIL PROTECTED] Kenny Drobnack writes: : This may be a stupid question, but what's to keep from putting xfs in : FreeBSD? Is there something in the licenses that says you can't use : GPL'ed software and software under the BSD License together? The BSD license allows binary only applications, while the GPL doesn't. However, keep in mind that the GPL has never been tested in a court of law, so how a judge will react to it, and which provisions are legal and which ones constitute unfair or extreme consequences have not been determined. One could argue for years on end about what it says and what other cases have shown, but at the end of the day you still don't know with certainty how it will fair in court. That's why we have a GPL math emulator, but don't include it in the GENERIC kernel. There are many people that repackage FreeBSD for embedded applications who do not include the source code to their proprietary bits and strip out all or most of the GPL software from their deliverables to avoid this potential legal quagmire. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : What do you all think about growing a gnu subdirectory in src/lib/libcompat? : Things like a getopt_long implementation (yes, if it will be accepted, : I am volunteering to write it...) would go there, and all sorts of lame : GNU libc cruft that we can try to be more compatible with. src/gnu/lib/libgnucompat might be better if is was GPL code. We've been trying to keep GPL'd code walled off from other code in the system. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
In message [EMAIL PROTECTED] Steve Kargl writes: : If you're writing unencumbered code, placing it under : libcompat/gnu may lead to confusion because all other : directory paths containing gnu contain GPL'd code. : Just stick it into libcompat. Or libiberty :-) That way we can have a GPL-free libiberty, which would be something that many people would want. It would also force the FSF to move more of their code from GPL to LGPL since it is stallman's policy to release things under the LGPL when there are alternative interfaces available. Although the recent hacks by [EMAIL PROTECTED] to generically wrap any library in rcp calls so that the progrma using the library doesn't have any GPL tainted code compiled into its address space might change that I hate the GPL. It has too many different interpretations. Look at the currentsituation with Linux: Linus says loadable drivers in Linux aren't covered by the GPL, while Stallman insists that they are. Its interpretation is open to too many variables :-(. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : There : is simply no reason to assume that anything under a gnu directory is GPLd, : or that anything GPLd is going to be under a gnu directory (which it's not.) I'm afraid there is. It has been stated many times in the past that all GPL'd software resides under gnu. This is true in the big (/usr/src/gnu) and in the small (src/sys/gnu). The gnu directory name is magic in the minds of many people, and has been for a long time in the FreeBSD project. While much of the actual software lives in /usr/contrib, those parts that are under GPL are still built in gnu/ It is confusing, despite your assertions to the contrary. That's just how FreeBSD has operated for as long as I can recall, certainly back to the 1.0 time frame. glibc or fsf do not carry these long term connocations. To some they might connote gpl'd code, but they are better choices for naming in the libcompat tree since it doesn't have the traditionally overloaded "gnu" term plus tell what the code is compatible with (which is how the directories in libcompat work. Contrib doesn't have a separate gnu dir, but that is irrelevant. Nothing is built in the contrib tree. It is all built in usr.bin or usr.sbin or gnu/usr.bin, etc. All the GPL'd parts of the contrib tree are built under gnu/... (it is a bug if they are not). Using it to support a gnu directory would likely have negative impact on the strength of your argument. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
In message [EMAIL PROTECTED] "Louis A. Mamakos" writes: : It violates the "starts with alpha" "requirement" in 952 and 1101 : that you quotes, yet we use these things all the time. That requirement has been relaxed. See RFC 1123. Bottom line is that _ is an illegal character in a hostname, and FreeBSD is behaving correctly. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
In message 25455.934497542@localhost "Jordan K. Hubbard" writes: : So Solaris does the right thing by understanding underscore I guess. : Since it is not forbidden to use it in hostnames. : : It does not do the right thing and it is indeed forbidden. :) Also, all modern versions of bind specifically prohibit all characters that are not allowed to make writing buffer overflow easter eggs much harder. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
In message [EMAIL PROTECTED] Narvi writes: : Nintendo 64 uses MIPS. : : : Which doesn't matter all that much. MIPS cpus for nintendo could be made : by say MISP, not SGI (and SGI sold/is trying to sell MIPS). Acutally, the Nintendo 64 uses the Vr4300 series of chips from NEC. I think the new Nintendo will use a different (non-mips) processor, but I'm not completely sure what the new one will be (when NEC announced this, MIPS stock took a dive). SGI has already spun out MIPS and has been slowly reducing its stake in MIPS for some time now. However, there is another gaming machine based on a 128bit MIPS design in the pipeline from, I think, Sony. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
In message [EMAIL PROTECTED] "Daniel O'Connor" writes: : How about just adding some flags to mount and modifying UFS so that : you can override the uid/gid on mount.. I assume you mean Joe uses : something like sudo so he can mount the disk.. Doesn't umapfs do that? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Onstream?
In message [EMAIL PROTECTED] Christopher Masto writes: : Do they still not allow you to release the specs? How is the code : going to become part of FreeBSD if they won't allow its release? I didn't sign an NDA to get my copy of the spec or the hardware... I also don't have time to devote to the onstream IDE project. I'm looking for someone with the kernel skills and track record to take over for me. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: lpd security check for changed-file vs NFS
In message [EMAIL PROTECTED] David Scheidt writes: : Couldn't you turn it off only for NFS mounted files? For the general case (eg the code checked into the system), the check needs to remain enabled. Anything else is insecure. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device_add_child??
In message [EMAIL PROTECTED] "David E. Cross" writes: : I have been writing a nasty kludge to treat a CardBus bridge as a standard : PCI bridge (with static config) you may start throwing rocks now. Ewe. Yuck. Wouldn't it be better to help the pccard/cardbus efforts :-) : I have : it to the point where I can (after the system is booted) 'pciconf -r : pci5:0:0 0' and get scan information (neat, huh :). Welll, I thought it would : then just be a simple matter of 'device_add_child(dev, "pci", 5, 0);' to get : the bus to show up at PCI5: at bootup, but it seems to ignore it. following : from pcisupport.c I also tried to 'bus_generic_attach()' it after : device_add_child() finished. no go. Any suggestions? device_add_child just adds it to the tree. It doesn't probe or attach it. If you kludge adding it into the tree, you'll have to kludge attaching it. You might want to look at my pccard kludge-o-matic for examples. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: from number to power of two
In message [EMAIL PROTECTED] Nick Hibma writes: : Does anyone know an inexpensive algorithm (O(1)) to go from an number to : the next (lower or higher) power of two. 1 ffs(x) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pthread_set_concurrency()
In message [EMAIL PROTECTED] Nate Williams writes: : Your definition of kernel threads and mine are obviously quite : different. :) True. The kernel "threads" are just process context that a task can run in Lots of thread-like things are missing... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
When I did a remote geographic disk based mirroring product a few years ago, I just had an ioctl that said that this disk was special for a while. Then the open routine would fail. This flag was cleared in the close routine (and by the companion ioctl). I did allow users to open the device w/o read and write to get status on the device, but that was it until the rebuilding process was complete. Granted, this was the control device for the mirroring driver... But that worked fairly well. I only needed to do this in recovery situations for a few hundred disk I/Os, so the average user would likely have never noticed. Oh, this was on Solaris, but the concepts are exactly the same for FreeBSD. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [freebsdcon] radisson reservation
In message [EMAIL PROTECTED] Bill Fumerola writes: : It took me 10 minutes of explanation for the reservation clerk to finally : figure out just what the hell I was talking about. WC CDROM did the : trick. My clerk just started reading down the names. When I heard walnut creek cdrom, I said "ding ding ding ding ding ding. We have a winner." and there was a pause and then I got the rate :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: (forw) FreeBSD (and other BSDs?) local root explot
In message [EMAIL PROTECTED] Julian Elischer writes: : quickest fix would be to make the core-dump routines not follow symlinks. An even quicker fix would be to disable coredumps in periodic, since no reboot would be required. :-) As has been noted in -security, the kernel fix has been committed. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Seeking testers for change to lib/libc/gen/fts.c
In message [EMAIL PROTECTED] Peter Holm writes: : The patch is available at http://www.freebsd.org/~pho/fts.diff You might want to work with Bruce Evens who has patches as well.. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
In message [EMAIL PROTECTED] Kris Kennaway writes: : Could someone do this before 3.3? It's useful functionality. As the committer of this feature, I've just sent mail to jkh asking for permission. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More than 32 signals. Thought?
In message [EMAIL PROTECTED] Sheldon Hearn writes: : : : The Linux trick I like to add is to have sigset_t always be the last : field in structures so that the impact of enlarging sigset_t is : minimal. : : On LITTLE_ENDIAN machines? Endian shouldn't matter. An array at the end of a struct is going to grow that struct in identical ways... If the array index is defined sanely, then no one will notice if the lenght is passed in. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
In message [EMAIL PROTECTED] Poul-Henning Kamp writes: : Hmph. I guess common sense wins over ITAR in this case. :) : : That's certainly an improvement in that particular battle :-) Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StarOffice giveaway of source code
In message [EMAIL PROTECTED] The Hermit Hacker writes: : From a marketing standpoint, wouldn't it make for some seriously bad press : for Sun to state "open source" and then turn around and not do it? *raised : eyebrow* Those who don't know about history are doomed to repeat it. Sun originally released Java in a fairly free and open way, then layer went back and tightened things ot the point that open source groups could not get copies. They fixed that, but Sun can be schizophrenic at times. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
In message [EMAIL PROTECTED] Sheldon Hearn writes: : This has nothing to do with what's in the base system. This has to do : with making it easier for people to run 3rd-party software, which isn't : part of the base system, in a non-priveledged state. I think this is a good idea. Plesae don't foget an "UPDATING" entry. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
