Re: Enhancing cdboot [patch for review]
This sounds and looks cool, diff looks OK (haven't applied), Luigi's comments seem well thought out and expressed. cheers BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone interested in HDLC support for pppd ?
[EMAIL PROTECTED] wrote: Hello; I started playing a bit with net/pppd23 and I noticed there are some patches for FreeBSD-3.0 that were never committed (NetBSD certainly has them). Our pppd(8) is derived from the samba pppd port and should have them if we want to continue updating it. Ed Schouten is currently rewriting the tty code. It sounds like line disciplines are about to go away, so pppd23 will most likely stop working at that point. There's a Netgraph node ng_cisco which claims to support HDLC. Perhaps tweaking MPD to work with it is a better use of effort. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On Wed, Apr 19, 2006 at 10:46:09AM -0400, Coleman Kane wrote: My point is that we should let our purist values get in the way of others' enhanced experience using the system. My view is: We take the patch, as long as it doesn't interfere with the internal machinations of rc too much. There are good aesthetic and functional arguments on either side. Given the excellent work on rc to date, we have clean abstractions in rc itself, so fitting colour-aesthetics in does not have a high maintenance cost. I agree strongly with the functional arguments however and think that this stuff shouldn't be turned on by default. I think that it should be available in the base system for those who wish it. I feel that this should be both for aesthetic reasons and for promoting FreeBSD to the ultimate end, that is, to potential users, who may find it easier to relate to FreeBSD if the console messages are in colour, no matter how irrational that may seem to some! Regards, BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: User mounting take 2
On Sat, Apr 15, 2006 at 01:05:45AM -0400, Joe Marcus Clarke wrote: Finally, in testing this, I found a problem with smbfs, msdosfs, and ntfs relating to the statfs(2) f_flags field. smbfs always set this to 0, msdosfs didn't set this at all, and ntfs set this to all flags (not just those visible to statfs(2)). By fixing this, umount(8) works properly on relative paths to user mount points for those three file systems. Very very cool. I've seen this behaviour before and it was annoying because it meant having to sudo to do user SMB mounts in my home directory. Thanks muchly for doing this work. BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
On Sun, Apr 09, 2006 at 06:48:25PM -0600, M. Warner Losh wrote: I though thtis was already supported. We export bus/slot/function information devd, which can be used to configure the device. If I've read the specs or code incorrectly please do let me know -- my reading here is based on the PCI code as I understand it to be. As I understand things, the bus/slot/function numbers in pci(9), the *slot* number isn't guaranteed to have any meaning in geographic reality; it's purely what the PCI logic thinks the bus topology looks like and hence what the device numbers are. See BUGS in pci(9). It won't tell you that a given card is in a given slot with any degree of certainty or consistency across the range of backplanes available from multiple vendors -- although people may like to give PICMG a try as I hear such boards are consistent about such things. In the old Microsoft-specified $PIR tables there was a column which allowed you to map the bus/device/function tuple we use to a physical slot number, but this only ran 1-6. With multiple PCI buses and slot types, as well as multifunction devices, this information quickly became unusable and unreliable, although src/tools/tools/pirtool will happily display this information. ACPI as you no doubt know does away with the $PIR tables, although many BIOS still export them to allow legacy DOS programs which use PCI to work. There is an extension to ACPI which adds geographical slot addressing to the device tree but I haven't seen any systems which support it. Regards, BMS P.S. I have some notes somewhere about the ACPI geog stuff but can't remember if I posted them or filed them elsewhere -- check the XORP mailing lists, I think we bashed this out there around 14 months ago. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
Mike, Tell me about it, I know exactly what you mean! On Sat, Apr 08, 2006 at 06:53:11PM -0400, Mike Meyer wrote: My question about labels for ethernet devices wasn't meant to be rhetorical. Ethernet device names on Unix are pretty much worthless. They tell you basically nothing about which device you've got. On FreeBSD, different card types have different names, which is better than nothing - but that's about all it's better than. We need something akin to labels for ethernet devices. The LAN it's plugged into is the equivalent of the data on the disk - but there's no equivalent for the label. What do I want for that? I identify ethernet boards by which slot on the back of the system I plug the cable into. Currently, I have to map that to board types to and which board is plugged into which slot to know which name to use. I want a name that tells me which slot I plug a cable in to plug it into that interface. I investigated this problem when doing research on XORP. The behaviour you describe is a functional requirement for a router chassis. What it really comes down to is that one needs a PCI variant which supports what's known as 'geographical addressing', and for FreeBSD's device / ifnet framework to support naming cards according to the geographic i.e. physical address. If you look at the very bottom of the man page pci(9) you'll see I've left a footnote about this. Unfortunately the only systems which tend to implement this feature at the moment are CompactPCI based chassis systems. Although there is support for geographical addressing in a recent ACPI spec but as far as I know it may only really have made its way into blade systems. Hope this helps. Regards, BMS P.S. If etiquette were taken more seriously then society as a whole might function better -- I think of it as part of the 'operating system' of the human spirit! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: copy paste in freebsd
On Fri, Mar 24, 2006 at 01:52:20AM -0800, Divya B wrote: Here is the problem i am facing with freebsd. 1. copy some text from a file or any window 2. close the file or window 3. try pasting it in another place. Paste is not happening. Is freebsd lagging in this? Or have I missed something? FreeBSD is an operating system; it's not an integrated graphical environment. It is easy for novice users to be confused about this. You haven't told us here if you're using the text-based console, the X windowing system, or any particular combination of X terminal program and/or window manager, so it's difficult to offer useful advice. If the former, it could be a FreeBSD issue, i.e. with moused or the console driver, but you have pointed out that you're using a window, so I will assume you're using X (this implies it is not a FreeBSD issue). Traditionally X's clipboard support has been threadbare at best. Having said that, you may wish to try a clipboard manager program of some kind if this sequence of events is a problem for you. I would suggest you try installing KDE or GNOME or a similar environment and see what works for you as the concept of 'clipboard' is treated very differently by such environments. Regards, BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
On Thu, Mar 16, 2006 at 01:59:52PM +0300, Artem 'ZaZooBred' Ignatiev wrote: I need some help regarding newbus architecture. I'm trying to write driver for budget DVB cards. I think Sami Bahra was going to port Video4Linux, so search archives and check in with him. I had a DVB card but gave it away 2 weeks ago. For IP over DVB info, check out Gorry Fairhurst's papers. BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: watching a file for ownership change
On Sat, May 21, 2005 at 10:38:30PM -0400, Charles Sprickman wrote: I'd like to find a way to watch one of the user's maildirsize files that seems to flip ownerships at least once a day and try to determine what process is changing the ownership. How can I do that without dropping a bunch of daemons on a production machine into heavy-debug mode? OS is 4.8 with all current patches. You could try watching kevent() on the file for EVFILT_VNODE with NOTE_ATTRIB. You'd need to write a small C program to do this. Whilst this won't tell you who did what, it could give you sufficiently good timestamps from it happening to begin tracking the culprit down further, perhaps using lsof. BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Accessing BIOS memory range
On Thu, May 12, 2005 at 09:58:10PM +0200, alexander wrote: I'm writing a little app in 32 bit x86 (386 minumum) assembly, where I need to access some memory in the BIOS range. The real address is 40h:6Ch (virtual = ((0x404) | 0x6C)). Just use /dev/mem. It will do what you want. Look at src/tools/tools/pirtool for a simple example. BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCI Programming
On Thu, Apr 28, 2005 at 07:39:33PM +0200, Cole wrote: If anyone has any sample code or anything that I could read to proceed any further, it would be greatly appreciated. Have a look at the man page in section 9 for pci. You should be able to find most of what you need there. You should probably also look at one of the simpler PCI drivers in the kernel tree to see how similar things are done in FreeBSD land. Though it looks like the idiom you're trying to port may not be needed (you can just match the IDs in your driver's probe or attach routine, when the pci bus parent driver calls them through NEWBUS). Regards, BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with: OSPF thru netgraph Gif Tunnels
On Sun, Apr 24, 2005 at 10:41:31PM -0700, Chris Bose wrote: I?m trying to setup a network between two locations over a WAN and I?m running into a wall when I try to get OSPF to talk over my WAN tunnel. I?ve realized that I?m not smart enough and need your help. I haven't looked in depth at the information but it sounds to me as though the most likely failure mode is that multicast isn't working over the gif tunnel for whatever reason. You could try configuring OSPF in NBMA mode over the tunnel, that way OSPF discovery isn't dependent upon multicasts being forwarded over the tunnel, but requires you to explicitly specify the OSPF peers at either end. Regards, BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: preadv() / pwritev()
On Mon, Apr 25, 2005 at 12:10:08PM +0200, Marc Olzheim wrote: Are there plans on implementing preadv() and pwritev() ? I kind of miss the functionality and I saw NetBSD had it already... By the looks of pwrite() and writev() it could probably be implemented fairly easily; it would largely be a matter of rototiling pwrite() to accept an array of iovecs, as writev() currently does, as pwrite() already knows how to pass a single uio/iovec on the stack with the desired start offset. Looking at the man page for pwritev() it only accepts a start offset, rather than an individual offset for each scatter/gather element. I don't do enough thread-based programming at the moment to make this worth my while, though, but I'm happy to look at a patch. BMS pgpClgMnMoRjH.pgp Description: PGP signature
Re: preadv() / pwritev()
On Mon, Apr 25, 2005 at 06:50:41PM +0200, Marc Olzheim wrote: More like this then... Yep, something like that! Thanks, though I may not have time to commit this at the moment. :-( BMS pgpzcrqJRUpsG.pgp Description: PGP signature
Re: A question about hot-pluggable PCI.
On Mon, Apr 11, 2005 at 11:21:14AM -0600, M. Warner Losh wrote: No we don't. We use what the BIOS provides, but will lazily allocate the BARs as necessary. We don't open the resource windows on the bridges, however. This 'sorta' works now. I program a hard-coded window into the PCI bridge behind CardBus. Drivers attaching to devices behind the bridge are able to get the ranges they need, with the exception of the ATA controller inside the chassis, which I know is a special case for PCI. This of course is a hack which may not work for the !i386 case, as it relies on the HUB-PCI bridge behaviour of Intel chipsets, which is to pass all transactions across (according to some of the comments in pci_pci.c). It turns out interrupt routing is the problem. I don't think it's possible to route an interrupt across CardBus to a downstream PCI bridge in the same way as is usually done for PCI-PCI bridges. When I added the following, I found drivers attaching to devices inside the chassis were able to allocate interrupts and service them:- %%% +if (!strcmp(device_get_name(bus), cardbus)) +intnum = 11; /* Hardcode the IRQ routed to my CardBus bridge */ +else intnum = PCIB_ROUTE_INTERRUPT(device_get_parent(bus), pcib, parent_intpin + 1); %%% ...whereas normally the code was 'routing' IRQ 6 to INTA on the bridge. I don't see a pcib_route_interrupt method for pccbb, which is the grandparent of the pcib instance I'm attaching. So I check if the devclass of the immediate parent is cardbus. This suggests that the code may have been erroneously routing an interrupt from 1 level up in the PCI bus hierarchy, which would explain why cbb was rejecting drivers downstream asking for IRQ 6 (my function interrupt is IRQ 11, I have no idea what IRQ 6 is, so I'll reject the allocation). However, it looks as though this doesn't do the right thing just yet, because drivers panic on detach when calling bus_release_resource() for their IRQ. : I had also thought of passing down a 'cold' flag, for pcibX to indicate to : pciY that this is a 'cold attach' (the BIOS hasn't been anywhere near the : devices behind this bridge -- it is as fresh as after a RST# assert). I don't think that's a wise idea. Currently, in pcib_attach(), after the call to pcib_attach_common(), I check to see if sc-secbus is 0. If it is, I call a new function, pcib_attach_cold(), which tries to initialize the bridge as if the BIOS had never touched it. So far this 'kinda' appears to do the right thing; the onboard OHCI controller gets its resources OK. I imagine some of the code from this effort could be cleaned up and pushed back into the tree to support other forms of PCI hot-plug in future. BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel killing processes when out of swap
On Tue, Apr 12, 2005 at 05:24:15AM -0700, ALeine wrote: machine. Having a flag to tag processes as vital to prevent them from getting killed (or to give them lower next-to-be-killed priority so that all non-vital processes get killed first) when you run out of swap would be a useful feature, P_SYSTEM provides something like this feature, amongst others. It is used by init(8). However P_SYSTEM also says that process statistics should not be maintained, and that the signals that may be dispatched to such processes are restricted. It would be more appropriate if such processes use the mlockall(2) call for the time being. BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
A question about hot-pluggable PCI.
Hi, I have acquired a Mobility Electronics EasiDock 5000. As some of you may already know, this is a device which allows you to connect regular PCI cards to your laptop, using a device called a 'Split Bridge'. (*) Ok. Cool toy, you may be thinking. Indeed. But I want to make it work with FreeBSD. (+) I'd love to hear from anyone who has plans to implement hot-plug in a BSD, because this is the missing piece of the puzzle currently. It seems that this device is known to work with Linux, with some further hacking of support which Magma (who acquired Mobility a few years back) provide on a 'as is' basis. So I've begun hacking the pci and pcib drivers from RELENG_5_4 to support this device. So far, I've been able to probe configuration space. I see all the devices on the PCI bus inside the expansion chassis. However I cannot get drivers to attach properly, because resources have not been assigned to the cards. Normally the BIOS would do this. But because BIOSes do not normally explore beyond the CardBus bridges, none of the devices have had their I/O, memory, or interrupt registers set to non-default values; everything is the same as a pristine bus reset, even when I boot with the bridge card in a CardBus slot. In order to get this far I've had to add NEWBUS detach methods to both pci and pcib, as well as some cleanup in pci_pci.c, and some downright dirty hacks to deal with subordinate bus numbering which rely on the current behaviour of our CardBus driver. I'll post diffs if anyone else is interested; but right now it's pretty trivial stuff. Cheers, BMS [(*) It is so called because unlike a normal PCI-PCI bridge, the bridge is 'split' in two; there is a CardBus card which goes into your laptop, to which is connected a proprietary high-speed serial bus cable. At the other end is a PCI chassis which looks much like any other desktop PC, which has a jack for the proprietary connector out of the back, wired up to the other half of the 'split bridge'; this sits on a passive PCI backplane with several ordinary 33Mhz 32-bit-wide PCI slots.] [(+) Yes, I know, if OpenCores.org had a PCI IEEE 1394 cell which could just tunnel arbitrary PCI I/O and configuration transactions, we could implement this thing using $20 cards from a chain store. If only.] pgpQ9Kdjbhr1U.pgp Description: PGP signature
Re: A question about hot-pluggable PCI.
On Mon, Apr 11, 2005 at 07:25:07AM -0600, Scott Long wrote: Asking for 'hotplug support' is pretty generic and non-descriptive. Are you asking for device level hotplug support, where we carefully drain transactions out of a device, device driver, and whatever I/O or network or whatever layers are above it? Or are you talking about PCI hotplug support? If so, which de-facto standard? Compaq? IBM? ACPI? PCI-SIG? Something else? Sorry, I thought my original post was quite clear; in order to support my hot-pluggable PCI chassis, FreeBSD needs to grow the ability to manage PCI resources without any firmware support (other than possibly the ability to route interrupts). Since I sent that mail I looked at the requirements list for 5-STABLE and realized this is in fact on it. I think there's a fair chance that any other PCI hotplug standard is going to need the same changes I need to make my split bridge work. I looked in src/sys/dev/cardbus/cardbus_cis.c, and Linux's ACPI-based PCI hotplug driver, and realised that at the lowest level, they are all in fact pretty much doing the same thing -- that is, setting all bits in a BAR, and then figuring out the desired aperture size for each BAR, allocating the appropriate resources using rman, figuring out base addresses, etc. We currently rely on the BIOS to do this. The bit I've been discussing with Warner is how to deal with the problem of setting subordinate bus numbers, though because I can get away without doing that for the 'pcib is an immediate child of cardbus' case, I haven't done it. I had also thought of passing down a 'cold' flag, for pcibX to indicate to pciY that this is a 'cold attach' (the BIOS hasn't been anywhere near the devices behind this bridge -- it is as fresh as after a RST# assert). That's enough for me to be getting on with just now, though it would be nice to have some general architectural advice on where exactly this logic should go, because it's something cardbus is using to mop up the edge cases where device resources are not fully described in the CIS. I am undecided as to whether I should try to separate out my changes to src/sys/dev/pci/pci_pci.c into a new driver or not. BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: name cache cont.
On Mon, Mar 28, 2005 at 05:42:52PM +0400, Igor Shmukler wrote: For my purposes the Linux/DragonFly functionality is needed. Is there a way to know that once a patch that correctly resolves corner cases for vn_fullpath() (including name cache changes) exists it will be committed to the 5.x branch? Hey, I did some of this work quite some time ago. It is still floating around in the archives. I'm more than happy for people with more vfs knowledge than I to pick it up, review it, and commit it, but I don't have free time to do this right now. BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: relation between PQ_CACHESIZE and PQ_L2_SIZE
On Sat, Mar 26, 2005 at 09:44:36AM -0800, Bao Zhao wrote: some think it is 4-way set associative,but I think it is the page's size-4KB. If I'm right, How BSD deals with 8KB page size? Please search this list's archives as there's a thread on this from a few years back (I was one of the protagonists). BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: poll or select for ppi?
On Mon, Mar 14, 2005 at 10:05:34PM -0500, Matt Kory wrote: Is it possible to use poll or select to detect a change in the status bits of the parallel port? I tried something like this, and took bits 5 and 6 of the status register low and nothing seemed to happen. Is what I am trying to do even possible, or I am supposed to take a certain bit low to cause a read event? Any help is appreciated. Disclaimer: I'm no expert on the parallel port. The man page for ppi(4) says that all I/O is via ioctl(), which isn't covered by the select() mechanism. You'd either have to poll PPIGSTATUS from userland on a timer, or perhaps hack the driver to use a kevent. Considering there's probably no way to get a hardware interrupt for the status change directly via ppi(4), you might need to consider writing a set of custom ppbus microsequences and a driver for your application. Regards, BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Rawsock bpf mambo jambo?
On Tue, Jan 25, 2005 at 10:46:47AM +0100, DJF wrote: What's the advantage in using the rawsock bpf combination instead of bpf (or raw socket) only? Raw IP sockets for write take care of the following for you: 1) Computing IP checksums. 2) Inserting IP options. BPF does neither of those things. For a while BPF was read-only, but it has been read-write capable for quite some time. BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenBSD's netcat in base or ports?
On Tue, Jan 25, 2005 at 01:46:30PM -0500, Coleman Kane wrote: This is only my personal opinion. I think the WITH__OVERWITE_BASE make options help substantiate it, however. I've recently updated the tcpdump port to fix a number of issues. If people could confirm that the OVERWRITE_BASE option still works there, I should be most grateful. Regards, BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Resuming from a crashdump
On Mon, Jan 24, 2005 at 07:37:34PM -0600, Ryan Sommers wrote: My little knowledge on this subject aside. I'd love to have full suspend/resume functionality. It'd make my life as a mobile freebsd user much much easier. However, I wouldn't want it at the expense of every kernel. It would need to be something completely modular. I think what we're also looking at is aborting any pending bus-mastering transactions. This could probably be done as a part of the newbus suspend/resume routines for bus and device drivers, but it also means that the other entry points need to be able to deal with the carpet being dragged out from under them like this. In the case of a networking driver, particularly Ethernet, things are somewhat easier, and the more help you get from the hardware the better; but some cards like those based around ATM SARS just plain aren't designed to deal with the carpet being dragged out - they expect to keep rolling through their descriptor rings, segmenting and transmitting what they see. If we could take a clean subsystem-by-subsystem approach to marshaling kernel state to disk, that would be good. What gives me particular pain here is dealing with things like the filesystem. How does one deal with open files, etc, with pending I/O? Just my 2c, BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Wondering about a patch (DELL ERA/RAC)
On Wed, Jan 19, 2005 at 03:58:23PM -0800, dpk wrote: I just got a test server set up for this. The patch worked fine. I lifted a pppd command line from a linux mailing list: pppd /dev/cuaa4 1382400 crtscts noipdefault noauth lock persist connect 'chat -v CLIENT CLIENTSERVER \\c' and I'm able to access the device via the ppp0 interface. FWIW, I am using FreeBSD 4.10 here. Thanks for updating the patch! Committed to -CURRENT, MFC pending 1 week. Thanks! BMS pgppx57OF7jcb.pgp Description: PGP signature
Re: Kernel mode programming
On Tue, Jan 18, 2005 at 11:45:05AM +0100, - Felix - wrote: Doing lot of syscalls interrupts in a soft seems to take quite a long time, and seriously slow performances. As far as you can't reduce the syscall amount, is there any way to run apps in kernel mode, in order to call sysfonctions directly ? Perhaps by re-writing softs in kernel modules ? For 95% of applications syscall overhead shouldn't have a major impact on performance. It's difficult to offer any real advice here because you haven't said what the application is, or shown any profiling figures. Maybe you should review your design? Trying to avoid repeating what other posters have said here. BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Geode integrated peripherals support?
On Sun, Jan 16, 2005 at 03:01:17PM +0100, Milan Obuch wrote: ACCESS.bus support (i2c bus compatible) and LPC bus bridge (for expansion). The first one is present in OpenBSD. I am currently studying that and FreeBSD kernel sources to try port it, however, any help would be great. No idea on LPC, through... There's some i2c support in FreeBSD already, whether or not this applies to the i2c hardware in the Geode I don't know. iic(4) would be a good place to start. LPC just looks like ISA for most intents and purposes, and if we didn't support ISA, we couldn't boot on i386... BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ASIX AX88172 OS X?
On Mon, Jan 10, 2005 at 04:26:18AM -0600, Kris Tilford wrote: I assume your FreeBSD driver could be easily ported to OS X, I could [snip] Nope. MacOS X and FreeBSD are completely different in this area. It uses a driver API known as IOKit. Your best bet is to look for driver support from the manufacturer. Regards, BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Raw sockets problem?
On Sat, Jan 08, 2005 at 11:34:57PM +0100, Ivan Voras wrote: I use it in this code: /* get interface name by index */ ... Please consider using if_nameindex() or if_nametoindex(), which will retrieve the getifaddrs() list for you and considerably simplify the code fragment you've provided. These are specified by RFC 2553 and are used in many places within the XORP open source router. Regards, BMS pgpnKvYB8cZ9Y.pgp Description: PGP signature
Re: Wondering about a patch (DELL ERA/RAC)
On Sat, Jan 08, 2005 at 07:17:33PM -0800, dpk wrote:
Will this patch be making its way in to the kernel? The Dells are still
shipping with cards that have no drivers (this pciconf -v -l is from a
1750):
Please try the attached patch. You'll need to have these drivers
statically compiled into your kernel (with the patch applied)
device sio
device puc
I don't have one of these devices so I'm unable to test.
Hope this helps,
BMS
Index: pucdata.c
===
RCS file: /home/ncvs/src/sys/dev/puc/pucdata.c,v
retrieving revision 1.45
diff -u -p -u -r1.45 pucdata.c
--- pucdata.c 17 May 2004 12:57:30 - 1.45
+++ pucdata.c 10 Jan 2005 05:43:47 -
@@ -1203,5 +1203,14 @@ const struct puc_device_description puc_
},
},
+ /* Dell RAC Serial PPP Link */
+ { Dell RAC Serial PPP Link,
+ { 0x1028, 0x0008, 0, 0 },
+ { 0x, 0x, 0, 0 },
+ {
+ { PUC_PORT_TYPE_COM, 0x14, 0x00, DEFAULT_RCLK * 128 },
+ },
+ },
+
{ 0 }
};
pgpPjLZRU6Og0.pgp
Description: PGP signature
Re: network trunkin
On Sun, Jan 09, 2005 at 02:48:18AM -0800, Matt wrote: Does anyone know if FreeBSD supports trunking? By that I mean spreading network traffic over multiple interfaces to achieve a higher aggregate throughtput. I've used this with Solaris. Thanks. Were you thinking of any particular Ethernet trunking standard? I assume you're referring to Ethernet. ng_fec(4) is a Netgraph node which suports Fast EtherChannel, which is a Cisco-ism. It may not be what you want. The IEEE standard for Ethernet trunking is 802.3ad Link Aggregation (aka LACP in Cisco-ese). As far as I know we don't currently support 802.3ad. You might also wish to investigate ng_one2many(4), which is a bit more simplistic. Regards, BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UCARP support for FreeBSD
On Wed, Dec 08, 2004 at 01:02:09PM -0600, Scott M. Ferris wrote: ucarp will compile and run, but will silently fail to send heartbeats due to the way libpcap opens bpf on FreeBSD. You can find a patch to libpcap in PR 72814. http://www.freebsd.org/cgi/query-pr.cgi?pr=72814 This is something else which needs a pcap/tcpdump update. Currently there is no way to specify this behaviour at runtime. Hopefully this should be resolved at the next import. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: about a usb adsl modem driver
On Fri, Dec 03, 2004 at 09:25:56PM +0100, Jose M Rodriguez wrote: But noted strong differences between atm boards and adsl modems. - atm boards are hardware assisted. usb adsl modems are bare assisted. - atm boards support better signaling, multiple channels, ... usb adsl modems just one PVC with uni signaling. Not really. See below. So I realize that try to get a NATM/NETGRAPH hardware driver may be too work for little gain. Actually writing a NATM driver is far easier than writing a HARP driver. And Harti's newer drivers for ATM cards are, in fact, NATM drivers. You only need to implement Netgraph hooks. You don't need to worry about implementing Netgraph protocol nodes, generally. You might want to contact Benno Rice, he was working on a software AAL5 kernel module to augment netnatm, which would help if you're targeting the lower end ADSL hardware. Regards, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resolving routes externally
On Tue, Nov 23, 2004 at 11:05:06AM +0200, Martin Eugen wrote: At the beginning my intention was to use the routing sockets mechanisms, and say, to issue a 'missing route' message to some userland daemon capable of resolving those complex addresses (the resolving mechanism is generally a lookup in a local DB). But then I You're on the right track here. You might also wish to investigate the RTM_RESOLVE mechanism. realized there is no (Am I missing it?) code in the routing modules that could make the thread handling the packet sleep until the userland daemon is looking up the route. (I'm also still not sure if a 'netisr' thread is safe to sleep?) So I started to look at the ARP code, but it of course lacks the kernel - userland communication interface. I would appreciate any ideas about what would be the easier way to implement such a thing where the kernel could wait (up to some reasonable time-out) a userland daemon to install a new route. If I understand correctly, you want the kernel to queue packets until layer 2 address resolution is complete. Right now we don't do this. If there is no route to a destination, packets will be dropped. The ARP code implements a queue for each IP host address which is exactly 1 mbuf long (see llinfo_arp-la_hold). This holds the most recent packet that the host is attempting to transmit to the host pending MAC address lookup. All other packets will be dropped. Making a network stack thread sleep would be a Very Bad Idea. A more appropriate approach would be to use a separate netisr queue for packets which have pending external MAC address lookup. However, rather than calling netisr_dispatch() directly, you would want to call schednetisr() directly once the route resolution was complete. I guess this is non-IP traffic, in which case making the modifications which you need will probably be easier. Regards, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcsh fix
On Fri, Nov 12, 2004 at 01:50:24PM -0600, Kevin Lyons wrote: Presumably pure csh is the last stable release of csh before tcsh came along. Openbsd, netbsd, sun and sgi all seem to have been able to settle on a csh. I'm extremely happy with having tcsh instead of csh in the base system. As others have said, if someone has an operational requirement for plain old csh, they are free to install the port and make the appropriate links. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcsh fix
Hello, Misunderstandings such as this seem to be all too common in volunteer open source projects, sadly, and the resultant slagging match on mailing lists is counterproductive for all concerned. On Fri, Nov 12, 2004 at 04:53:58PM -0500, Charles Sprickman wrote: As an interested (and innocent) bystander, I'm not quite grasping why it's an either/or proposition. Why not just break the link, grab net/open's /bin/csh and commit it? Because we settled on tcsh 4 years ago, and no one has complained up until now, and making such a change now means going through all the vendor branch rigmarole for another shell in the base system, when the vast majority of people using the system are happy with the shells we already have, and alternatives are easily and readily available from ports. If person X wants shell Y which is not in the base system, and they wish to use they are perfectly free to use ports or maintain a local branch. The latter is non-trivial, the former, well, the time and effort involved in maintaining a port is far lower, and a port already exists for this particular case. Being abusive towards the volunteers who maintain something largely for free, and maintaining that something a bug when it isn't, when the answer to person X's problems is right in front of them, doesn't help anyone - it certainly doesn't help the person who wants the functionality of shell Y, and it doesn't magically inspire the volunteers who maintain the project to invest the non-trivial time and effort in creating a CVS vendor branch to maintain shell Y, which only person X has asked for. Regards, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcsh fix
On Fri, Nov 12, 2004 at 04:11:22AM +0100, Erik Trulsson wrote: Keep in mind that FreeBSD's /bin/sh is a more powerful shell than was available in, say, v7 Unix. Also keep in mind that ash is not POSIX sh (at least not as completely as one might like). This tends to bite me when using GNU autotools, which are hardcoded to prefer bash by default. Regards, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is the source to the system calls?
On Sun, Nov 07, 2004 at 04:29:42PM -0800, Dan Strick wrote: Does anyone know where the system calls are really defined? src/sys/kern/syscalls.master ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
c++filt is broken
c++filt is broken, at least on 5.3 and -CURRENT. It no longer builds
during a buildworld. This is really annoying for those of using the
base system compiler to build large C++ projects.
I've attached a Makefile which works for me; I haven't integrated it
into my local buildworld, though.
BMS
# $XORP$
S= /usr/src
.PATH: $S/contrib/gcc
PROG= c++filt
SRCS= cp-demangle.c dyn-string.c
CFLAGS+= -DSTANDALONE_DEMANGLER
CFLAGS+= -Dxmalloc=malloc -Dxrealloc=realloc
LDADD+= -lgcc
NOMAN= defined
test: ${PROG}
${.OBJDIR}/${PROG} ${.CURDIR}/sample
.include bsd.prog.mk
N11__gnu_debug14_Safe_iteratorIN10__gnu_norm14_List_iteratorIP7BGPPeerEEN15__gnu_debug_def4listIS4_SaIS4_E
pgpd4m13utwWf.pgp
Description: PGP signature
Re: Freebsd assembly programming - IN/OUT commands.
On Sun, Oct 17, 2004 at 09:46:29PM +0200, Jan Opacki wrote: Thanks for help. i386_set_ioperm() is exactly what i need. I have to say though I've had processes dump core the first time I've tried doing I/O port accesses after calling i386_set_ioperm() on 5.x since 5.0. This behaviour is sporadic. With opening /dev/io, I have had no problem. Also, the /dev/io method appears to work on amd64, whereas the i386_set_ioperm() method does not. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to access a device on LPC bus?
On Sun, Oct 17, 2004 at 01:50:11PM +0200, Thiemo Nordenholz wrote: beginner's question, maybe: How do I, from a device driver point of view, access a device attached to the Low Pincount (LPC) bus? Treat it as an ISA bus but write an ACPI attachment for it. Look at src/sys/dev/fdc/fdc_acpi.c:fdc_acpi_probe() for an example. unknown pnpinfo _HID=WEC0518 _UID=0 at handle=\_SB_.C046.C059.C140 There appears to be a Linux driver for this, which gives you something to work from. Now, to implement an identify function in a driver for this, I need to access data in the controller - but I don't have any information about its memory attachments... I'd suggest looking at that driver and accessing the registers you need to identify the device sub-type in your attach function. BMS pgpE1xHFvjl04.pgp Description: PGP signature
Re: execute a user process in the kernel
On Fri, Sep 24, 2004 at 06:21:25PM +0200, Dag-Erling Smørgrav wrote: You could, of course, write a kernel API for creating processes from scratch. They'd still need a parent, but you can use init(8) (pid 1) for that. If we were to implement POSIX spawn(), we'd need something like this. So this may be worth looking at. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: execute a user process in the kernel
On Sat, Sep 25, 2004 at 01:35:07PM +0200, Dag-Erling Smørgrav wrote: If we were to implement POSIX spawn(), we'd need something like this. Uh, no. posix_spawn(3) can be implemented entirely in userland and does not require any special kernel support. Discussions with peter@ and others on IRC have been ongoing regarding doing it in kernel space, so as to avoid unnecessarily expensive VM fork operations when 'spawning' a process. I'd be interested to hear more about your proposal for doing this in userland. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Global (non _KERNEL) place for sockaddr_union?
Greetings earthmen, On Thu, Sep 23, 2004 at 02:14:00AM +0200, Max Laier wrote: As no real solution has come up and we couldn't agree what to do with it either, I'll resort to an easy hack: http://people.freebsd.org/~mlaier/sockaddr_union.fix.diff ... Any objections? [ I know it's ugly already. ] Looks fine to me; I agree that this workaround is not ideal but it is acceptable given the circumstances. Regards, BMS pgp6f5B4E5OKz.pgp Description: PGP signature
Re: execute a user process in the kernel
On Thu, Sep 23, 2004 at 08:18:14AM +, Gordon David wrote: Kqueue is a good method to notify the user. But I want the code in the kernel directly calls a user program. This is Very, Very Hard indeed, because it's not something supported by the system, but it should be possible. Look at create_init() and start_init() and see if they can be adapted to your needs. The hard part here is building the process image. Good luck. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Error 1802: IBM T41 doesn't like other network cards
Hi, On Thu, Sep 23, 2004 at 09:57:25PM +1000, Phillip Crumpler wittered thus: Anyone else has similar problems? BMS@ reported ditching the Centrino card in his T40 but didn't mention if he replaced it with something else. I used an official IBM Atheros part, so I didn't run into this problem. http://www.ussg.iu.edu/hypermail/linux/kernel/0406.1/1048.html The quickest way to do this is to use the DOS program linked to above. Porting the CMOS code to FreeBSD is fairly trivial for someone who knows, though, but you probably don't want to wait. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Global (non _KERNEL) place for sockaddr_union?
On Mon, Sep 20, 2004 at 02:50:40AM +0200, Max Laier wrote: My question now is, what would be a good place to define this? Are there any fromal standarts that might define it already? (Couldn't find anything) Is there anything else that I must consider? I think Brooks' recommendation is sound and should probably be followed as it's fairly close to my original recommendation to you in private. The problem is that the definition of the union depends on what you wish to use it for, and which address families are visible to the application or kernel module which is using the definition. You may find that such a definition has to have conditionalized members. This is usually not a problem so long as they are all the same size. And a sockaddr union embedded in a struct probably should have a member with type 'struct sockaddr_storage' if it's to support all address families in future, although this commits more storage in the enclosing struct and may waste space in some cases. As you point out, you cannot do this in pf, as it defeats the intent of keeping larger members out of the table in the first place, and the union is there to make some casts go away. If it's any consolation, I'm going through very similar pain with XORP's new firewall manager right now with respect to address families (and templatized C++ classes). Regards, BMS pgpwv1vXE9d9A.pgp Description: PGP signature
Re: ZFS
On Thu, Sep 16, 2004 at 11:00:44AM -0500, Sam wrote: Yes, it's a single filesystem. But the storage most likely won't be all in one place. Making it look like it's accessible from one place is a good thing. ... are you hinting at multiple globally remote block accessible storage sets? Otherwise I'm at a loss. To the best of my knowledge, no, ZFS/DFS is only accessible locally on the machine it's mounted on. But the block storage can be scattered across multiple devices. It can be exported via NFS, this much I know. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS
On Thu, Sep 16, 2004 at 11:12:16AM -0400, Kevin A. Pieckiel wrote: Where on earth would you find a disk system that can store 2^64 bytes of data or larger, anyway? Don't physical and technological limitations limit the total capacity of even the largest hard drives now available? It would take millions of drives, or more, to create a single 2^64 byte logical drive. You can bet that somebody, somewhere, needs this right now. And someone will definitely need it in the next 5-10 years. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting encrypted
On Tue, Sep 07, 2004 at 01:54:43PM -0700, [EMAIL PROTECTED] wrote: If the authorization mechanism is limited to plain text, then yes. I know that strings can be used to attempt to find the passphrase in the load, but there may be ways to prevent the passphrase from being retrieved in this manner. On the other hand, you could use TCPA. Support for the TCPA chips found in many recent IBM machines, particularly the ThinkPad T4x series, was written for NetBSD by the folks at CITI. It's on my wishlist. You could probably teach GDBE about TCPA key retrieval, but the upshot is, you still need to log in to the TCPA chip. However, if you activated TCPA and only allowed it to boot your FreeBSD-derived product OS, by means of their signature mechanism, then you might well achieve your stated aims. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Driver for Thinkpad Hotkeys.
On Mon, Aug 09, 2004 at 04:03:18AM +0200, Arne Schwabe wrote: IIrc correct the WLAN indicator is wired to the minipci for Thinkpads, at least the linux madwifi (which is basically our ath driver but our ath has not been updated for some very long time) has support for the IBM thinkpad wlan led. Maybe that is not the only method of talking to the LED :) GPIO pins, twiddled by the driver, according to Sam. The madwifi stuff does this. A more significant backport of ath features should really be done. If I find time, I'll certainly help, given that ath is now my primary wireless connection. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: regarding timeout/untimeout kernel functions
On Thu, Jul 22, 2004 at 09:56:00PM -0500, Dan Nelson wrote: You could also use the kqueue/kevent functions to queue up an arbitrary number of timer events in a single process. I wrote a small routing daemon which uses kqueue/kevent to fire a period timer on a quantum which in turn calls into a timer list module I wrote, which can either use the kevent quantum, or multiplex on a single itimer. It's pretty basic and probably not foolproof, but it seems to work well. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Article on Sun's DTrace
This recently caught my eye: http://www.samag.com/documents/s=9171/sam0406h/0406h.htm There are a number of good sounding suggestions in there. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SPDIF capture device?
Hello, On Fri, Jun 18, 2004 at 01:56:25PM +0200, Ing.Richard Andrysek wrote: I've read your question about SPDIF capture device on freebsd. I am currently looking for similar device.Have you found such one? Can you access subcode etc.? The Soyo Dragon Plus! K7V has a SPDIF input/output; this uses the snd_cmi driver. However, I think some machine specific incantations are necessary to use SPDIF mode, and I don't know what these are. I have such a board but it's not in Desktop use (it's in my CVS server). Some reverse engineering is probably needed here, but if the Linux drivers support this and a change can be crossported easily, I'll happily commit it if people have the means to test it. Regards, BMS pgpklEdbveJRY.pgp Description: PGP signature
Re: memory mapped packet capturing - bpf replacement ?
On Mon, Jun 14, 2004 at 10:15:14AM -0700, Julian Elischer wrote: don't forget that bpf is not copying the entire packet, just the header.. If you look at Sergey's benchmark.c, you will see that the snaplen was set to 32KB. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: memory mapped packet capturing - bpf replacement ?
On Mon, Jun 14, 2004 at 08:38:57AM -0400, Ed Maste wrote: Hello Sergey. I haven't looked at your code, but I'll provide some comments, having implemented a mmaped ringbuffer BPF replacement myself. We've had some prior interest in this. Do you have patches? If so, I'd be more than happy to look at them. Linux has something similar, but when I looked at the mechanism involved, I was loathe to adopt the same logic because the buffer(s) involved were allocated from userland and then mapped accordingly; we generally can't afford to take a page fault in that path, for mutex related reasons. Regards, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: api for sharing memory from kernel to userspace?
On Wed, May 19, 2004 at 03:29:09PM -0700, Steve Watt wrote: On Wed, May 19, 2004 at 05:29:07AM -0700, Alfred Perlstein wrote: + I need to share about 100megs of memory between kernel and userspace. + + The memory can not be paged and should appear contig in the process's + address space. Any suggestions? + The way we accomplished this in some other operating system was to create a shared memory segment with an implementation-reserved name, and then have the application shm_open the name and mmap it in. Shouldn't be hard with a device driver. This sounds like the way to go. The way I achieved this with a PCMCIA memory card was to kmem_alloc_nofault() a range and then pmap_map() it, then handle mmap() as per the regular character device case. Do bear in mind that 100 megs is quite large in relative terms, so it's possible that kmem_alloc_nofault() would fail. Regards, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: passing messages to routing sockets
On Fri, Apr 09, 2004 at 08:02:30PM +0300, Vlad GALU wrote:
I understand that in order to add a new route to the routing
table, one must fill a buffer with an ifa_msghdr header, followed by three
socked adddress structures, representing the destination net/ip, the
netmask and the gateway.
[routing table suckiness snipped]
Could anyone provide a quick/small example on how to fill this
member ? I don't really understand what I should write into it.
It's a sucky one and I had to stare at src/sbin/route/* for a while til
the penny dropped. The netmasks in particular are packed in in a format
which isn't immediately obvious.
Have a look at the attached code, in particular, reply_rtmsg_resolve().
Also have a look at Section 19.11 of TCP/IP Illustrated Volume 2, and
Section 18.9 of UNIX Network Programming 3e Vol 1.
The API sucks, and it's something we'd like to change in future.
Regards,
BMS
/* $FreeBSD$ */
/*
* This is a hack to demonstrate the concept of hooking for the
* RTM_RESOLVE message being sent from the FreeBSD routing code,
* as a means of looking up routes on demand using a routing protocol
* such as AODV.
* This code will probably be vastly cleaned up and tested more thoroughly
* before being used as the basis for a user-space BSD AODV implementation.
*/
/*
* Copyright (c) 2003 Bruce M. Simpson [EMAIL PROTECTED]
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
*must display the following acknowledgement:
*This product includes software developed by Bruce M. Simpson.
* 4. Neither the name of Bruce M. Simpson nor the names of co-
*contributors may be used to endorse or promote products derived
*from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY Bruce M. Simpson AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL Bruce M. Simpson OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#include sys/param.h
#include sys/file.h
#include sys/socket.h
#include sys/sysctl.h
#include sys/ioctl.h
#include sys/sysctl.h
#include sys/types.h
#include sys/signal.h
#include net/if.h
#include net/if_var.h
#include net/if_mib.h
#include net/if_types.h
#include net/if_dl.h
#include net/route.h
#include netinet/in.h
#include netinet/if_ether.h
#include arpa/inet.h
#include netdb.h
#include ctype.h
#include err.h
#include errno.h
#include paths.h
#include signal.h
#include stdio.h
#include stdlib.h
#include string.h
#include sysexits.h
#include unistd.h
#include ifaddrs.h
union sockunion {
struct sockaddr sa;
struct sockaddr_in sin;
struct sockaddr_dl sdl;
struct sockaddr_storage ss;
};
typedef union sockunion sockunion_t;
void usage(void);
int add_xresolve_route(char *ifname, struct sockaddr_in *sin, int bits);
int inet_cidr_aton(char *s, struct in_addr *pin, int *bits);
int create_if(char *ifname);
int destroy_if(char *ifname);
int if2sockaddr(char *ifname, struct sockaddr_dl *sdl);
int handle_rtmsg(struct rt_msghdr *rtm, int msglen);
int handle_rtmsg_resolve(struct rt_msghdr *rtm, int msglen);
int reply_rtmsg_resolve(struct sockaddr_in *sin);
/*
* We check for the existence of ifname.
*/
#if 1
#define _IFNAME disc1
#else
#define _IFNAME lo0
#endif
int rtsock = -1;
int created = 0;
char *ifname = _IFNAME;
void
sighand_term(int sig)
{
/*
* Destroying an interface is sufficient to delete the routes
* pointing to it.
*/
if (created)
destroy_if(ifname);
exit(EXIT_SUCCESS);
}
void
setup_signals(void)
{
struct sigaction sa, osa;
sa.sa_handler = sighand_term;
sa.sa_flags = 0;
sigemptyset(sa.sa_mask);
sigaction(SIGTERM, sa, osa);
sigaction(SIGINT, sa, osa);
sigaction(SIGQUIT, sa, osa
Re: wireless usb atmel driver
On Fri, Apr 02, 2004 at 04:25:08PM +0300, Anton Alin-Adrian wrote: I am killing myself trying to compile http://www.vitsch.net/bsd/atuwi/ driver on 5.2.1-RELEASE. Try the atuwi from my perforce tree. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Determining a program's shared libraries at runtime
On Wed, Mar 31, 2004 at 02:55:47PM -0500, Mike Heffner wrote: Is there a method in FreeBSD for a program to retrieve the current list of dynamic shared libraries it is linked against or has dlopen()'d? /proc/pid/map should give you what you need, but it needs to be read atomically, i.e. you can't use more than one read() call to retrieve the information so you probably want to cp it to a temporary file and read it. This also requires that /proc be mounted, which is not the default behaviour under -CURRENT any more. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: events when (de)associating or when cable is (un)plugged
On Sat, Mar 27, 2004 at 03:37:44AM +0100, Dirk-Willem van Gulik wrote: Suleiman, Thanks for all the help - I just hacked up the patch below and took http://green.homeunix.org/~green/linkwatcher.c for testing. I also had to add the LINKUP/DOWN in some non-mii using ethernet cards (as only miibus(4) seems to issue this event). Nice! I'll take a more indepth look at this when less pressed. Keep on hacking. Would be nice to hook up with the WirelessLeiden folks too... Good stuff, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel i8xx watchdog driver
On Thu, Mar 25, 2004 at 05:40:33PM -0500, Don Bowman wrote: SMI under freebsd? Ha ha... Good luck! It didn't look very easy. The SMM, for those who don't know it, is a virtual 86, real-mode thing, at a location in ram which is locked and unaccessible unless you are in smm mode :) If you are lucky, your bios didn't lock you out of it. I wrote code to unlock the SMM within FreeBSD last summer on an IBM T22 with the 440BX chipset. Here it is. BMS /* $FreeBSD$ */ /* * A tool for FreeBSD to discover SMRAM on i440BX based motherboards. * This isn't finished or complete, left as exercise for the reader. */ /* * Copyright (c) 2003 Bruce M. Simpson [EMAIL PROTECTED] * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software *must display the following acknowledgement: *This product includes software developed by Bruce M. Simpson. * 4. Neither the name of Bruce M. Simpson nor the names of co- *contributors may be used to endorse or promote products derived *from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY Bruce M. Simpson AND CONTRIBUTORS * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL Bruce M. Simpson OR CONTRIBUTORS * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. */ #include sys/param.h #include sys/types.h #include sys/fcntl.h #include sys/pciio.h #include sys/mman.h #include sys/memrange.h #include fcntl.h #include stddef.h #include stdlib.h #include stdio.h #include unistd.h #include strings.h #include machine/sysarch.h #include machine/vm86.h #include machine/cpufunc.h #ifndef _DEV_PCI #define _DEV_PCI /dev/pci #endif #ifndef _DEV_MEM #define _DEV_MEM /dev/mem #endif /* * It appears as though my ThinkPad does not map SMRAM at the default * location. This isn't too much of a surprise. Firmware is responsible * for reprogramming the default location, and has to issue an SMI * during boot in order to do this. The actual SMI handler code is * located at SMBASE+0x8000. A quick way of issuing the SMI is to use * the on-chip APIC. A number of vendor BIOS do it this way. * * Can we discover if the host bridge remaps SMBASE? Yes. * on the i440BX host bridge, check the SMRAMC register. * * There are two modes: Compatible and Extended SMRAM. Compatible mode * is meant to be backwards compatible with older BIOS PM code. * The C_BASE_SEG bits will tell you where the SMRAM memory * really is. Setting D_OPEN to high will let you get at the SMRAM memory. * * If your VGA controller mapping is active, it would be a good idea not * to use it while you're doing this. * * My ThinkPad's BIOS doesn't set the lock bit. * My ThinkPad's BIOS uses traditional SMRAM semantics. * i440BX Compatible SMRAM is hardwired to 0xA-0xB. * * By poking D_OPEN to 1, I was able to extract the SMRAM segment from * my machine. * # pciconf -r -b pci0:0:0 0x72 * 0a * # pciconf -w -b pci0:0:0 0x72 0x4A * # dd bs=0x1000 skip=0xA0 count=0x20 if=/dev/mem of=./foo * # pciconf -w -b pci0:0:0 0x72 0x0A */ #define I440BX 1 #ifdef DEF_SMM #define SMBASE 0x3UL /* default IA-32 SMBASE location */ #define SMSIZE 0x1UL /* default size of SMM area */ #endif #ifdef I440BX #define SMBASE 0xAUL /* default i440BX SMBASE location */ #define SMSIZE 0x2UL /* default size of SMM area (128KB) */ #endif #ifdef I440BX_HIGH #define SMBASE 0x100AUL /* default i440BX SMBASE location */ #define SMSIZE 0x2UL /* default size of SMM area (128KB) */ #endif #define I440BX_VENDOR 0x8086 /* Intel */ #define I440BX_DEVICE 0x7190 /* I440BX host-to-pci bridge */ #define CSR_SMRAMC 0x72/* System Management RAM Control */ #define CSR_ESMRAMC 0x73/* Extended SMRAM Control */ #define SMRAMC_D_OPEN 0x40 #define
Re: Intel i8xx watchdog driver
Correction... On Thu, Mar 25, 2004 at 11:26:59PM +, Bruce M Simpson wrote: I wrote code to unlock the SMM within FreeBSD last summer on an IBM T22 ^^ discover and map. with the 440BX chipset. Here it is. Half asleep here. Doh! BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel i8xx watchdog driver
On Thu, Mar 11, 2004 at 07:07:36PM -0600, Wm. Daryl Hawkins wrote: I would love to incorporate it in both source trees if possible. Before it goes into current, I need to make some changes so that it will work with Poul-Henning Kamp's new watchdog driver model. Hopefully, I'll get to work on that some tomorrow. I'll release a new version for current as soon as it's ready. Excellent, I was just going to suggest that. On the subject of 'bits and bobs that hang off buses', Stacy Millions wrote a driver for the FWH RNG, and Doug Ambrisko rolled some code to flash the FWH on an i845 chipset if memory serves... I am happy to look at your code once it fits better with what we currently have providing I have time. Good work BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel SysV IPC defaults.
On Wed, Mar 03, 2004 at 05:42:43PM +, Chris Smith wrote: Consider MSGMAX (max bytes in a message) and MSGMNB (max bytes in a queue) The defaults are MSGMAX MSGMNB, which is clearly backwards. I see this. How about the attached patch? I can understand people still using the SYSV IPC mechanisms for the sake of compatibility, but I suspect the purists are loathe to touch it. BMS Index: src/sys/kern/sysv_msg.c === RCS file: /home/ncvs/src/sys/kern/sysv_msg.c,v retrieving revision 1.52 diff -u -r1.52 sysv_msg.c --- src/sys/kern/sysv_msg.c 7 Nov 2003 04:47:14 - 1.52 +++ src/sys/kern/sysv_msg.c 4 Mar 2004 13:46:59 - @@ -72,15 +72,15 @@ #ifndef MSGSEG #define MSGSEG 2048/* must be less than 32767 */ #endif -#define MSGMAX (MSGSSZ*MSGSEG) -#ifndef MSGMNB -#define MSGMNB 2048/* max # of bytes in a queue */ -#endif #ifndef MSGMNI -#define MSGMNI 40 +#define MSGMNI 40 /* # of message queue identifiers */ #endif #ifndef MSGTQL -#define MSGTQL 40 +#define MSGTQL 40 /* max messages in system */ +#endif +#define MSGMAX (MSGSSZ*MSGSEG) /* max # of bytes in a message */ +#ifndef MSGMNB +#define MSGMNB (10*MSGMAX) /* max chars in a queue */ #endif /* ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Accessing sysctls from kernel
On Thu, Feb 26, 2004 at 02:10:40PM +0100, Ivan Voras wrote: In sys/sys/sysctl.h I see function kernel_sysctlbyname() that looks (to me) to be intended for accessing sysctl values from kernel, but for it's first parameter it requires a struct thread *td. What should I pass to it? (I'm calling it from inside a screensaver module) You could try lying about which thread you are, when you aren't in a userland thread: Cscope tag: kernel_sysctlbyname # line filename / context / line 1728 /sys/dev/vinum/vinumio.c vinum_scandisk error = kernel_sysctlbyname(thread0, kern.disks, NULL, 2741 /sys/dev/vinum/vinumio.c vinum_scandisk kernel_sysctlbyname(thread0, kern.disks, devicename, 3305 /sys/i386/i386/elan-mmcr.c init_AMD_Elan_sc520 i = kernel_sysctlbyname(thread0, machdep.i8254_freq, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Local APIC on FreeBSD/i386
On Mon, Feb 23, 2004 at 10:20:57AM -0500, John Baldwin wrote: As of 5.2, the 5.x branch will use the local APIC on UP systems. Yay! Hopefully my pseudo-NMI-on-ThinkPad-button hack to the ACPI DSDT will work.. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5)
On Mon, Feb 16, 2004 at 07:11:16PM +0100, Dag-Erling Smørgrav wrote: It can't possibly hurt. If the stack is already aligned on a better boundary (64 or 128 bytes), it is also aligned on a 32-byte boundary since 64 and 128 are multiples of 32, and the patch is a no-op. If only a 16-byte alignment is required, a 32-byte alignment wastes a small amount of memory but does not hurt performance. I believe that less-than-16 (and possibly even less-than-32) alignment is pessimal on all platforms we support. I'm not happy with the patch as-is and would be happier if a cleaner MI-way of expressing this were found. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding 'realclean' target to /usr/src/Makefile
On Sun, Feb 15, 2004 at 02:42:07AM -0500, Garance A Drosihn wrote: It occurs to me that the simple, reliable solution to this is to add a 'realclean' target to /usr/src/Makefile, such as: I don't have a problem with this. However, on a related but somewhat separate note: It would be helpful if it were pointed out in documentation somewhere that the path to the compile and source directories, when doing NFS kernel installs, has to be identical to those which were in effect on the build box due to the treatment of MAKEOBJDIRPREFIX during the modules build (and subsequent modules/* path creation). BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BDM under current
On Fri, Feb 13, 2004 at 10:02:47PM -0500, James Housley wrote: does anyone know whether i can use gdb + bdm under freebsd ? Probably not, I had it working well under 3.x, never really got it working in 4.x I wouldn't mind following this up, alas, I don't have any BDM gear here. It is something I'd really like to get into though. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2-current problem in Dell Poweredge 1600SC
On Fri, Feb 13, 2004 at 05:42:01PM +0800, Ganbold wrote: I installed FreeBSD 5.2 on Dell Poweredge 1600SC. However FreeBSD doesn't recognize network card. It has onboard Intel Pro 1000 card. You probably want to try loading the if_em.ko module. I recently installed 4.9 on a newer Optiplex machine with an em(4) card and noticed that sysinstall didn't pick it up right away, so I put if_em.ko on an MSDOS floppy and loaded it from within the 'post-install options' menu before installing (somewhat confusing). BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: XL driver checksum producing corrupted but checksum-correct packets
On Sun, Jan 25, 2004 at 01:13:28PM -0600, Mike Silbersack wrote: I suppose that one thing we could do in the long run to help detect this sort of corruption would be to import OpenBSD's TCP MD5 support and ensure that packets which fail the md5 or fail the checksum are logged so that they can be investigated. Of course, that's adding data to the packet, and heisenberg wouldn't be too happy about that. :) I'm porting this right now. It's a bit different for us... BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TCP MD5 (was Re: XL driver checksum producing corrupted but checksum-correct packets)
On Sun, Jan 25, 2004 at 07:59:32PM +, Aled Morris wrote: If you're talking about RFC2385 style MD5 as used for BGP authentication, I'd pay someone to make that work on FreeBSD (with Zebra/Quagga.) Someone already is, and I have patches for Quagga/Zebra ongoing... (how do you think I'm testing it? :-)) BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: XL driver checksum producing corrupted but checksum-correct packets
On Sun, Jan 25, 2004 at 01:13:28PM -0600, Mike Silbersack wrote: I suppose that one thing we could do in the long run to help detect this sort of corruption would be to import OpenBSD's TCP MD5 support and ensure that packets which fail the md5 or fail the checksum are logged so that they can be investigated. Of course, that's adding data to the packet, and heisenberg wouldn't be too happy about that. :) I'm porting this right now. It's a bit different for us... BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TCP MD5 (was Re: XL driver checksum producing corrupted but checksum-correct packets)
On Sun, Jan 25, 2004 at 07:59:32PM +, Aled Morris wrote: If you're talking about RFC2385 style MD5 as used for BGP authentication, I'd pay someone to make that work on FreeBSD (with Zebra/Quagga.) Someone already is, and I have patches for Quagga/Zebra ongoing... (how do you think I'm testing it? :-)) BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-hackers Digest, Vol 42, Issue 6
On Fri, Jan 09, 2004 at 03:57:07PM +, YACINE GHANJAOUI wrote: when trying to intercept UDP packet after changing the protocol number from 17 to a user one (99) in the ip_input.c file. when trying to regenrate the packet after inserting some bit errors an error message appears in the reciever telling that The udp checksum is incorrect even if i just change the ip Header. What do you think the problem is? You didn't read how UDP checksums were calculated, did you? Here is one free clue: Look at the definition of in_pseudo() and where it is used. Use the source. look! BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: switching between groups
On Tue, Jan 06, 2004 at 11:14:06AM -0500, Adil Katchi wrote: I was just wondering if anyone has any ideas how it's possible for a user that belongs to multiple groups to somehow limit his or her own capabilities by using only one of the n groups that they belong to and be able to switch between these groups? For example, if userA belongs to groupA, groupB and groupC, can userA enter a mode that would force it to only belong to groupA (or groupB, or groupC)? UserA whould be able to switch between these groups and back to normal (ie. belong to all groups). newgrp(1) could be hacked to do this fairly easily. Currently it preserves supplemental group memberships. An option to discard supplementals could be added. Or just call setgroups() with a no-op group-list vector and then setgid()/ setegid() from within your application. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
SGI ARC x86 boxen diffs
I've burned up too much time over the holidays on trying to get our loader pointed to ARC x86 on the SGI Visual Workstation, and didn't really get anywhere. If anyone has such a box and wants a starting point, go here:- http://people.freebsd.org/~bms/dump/loader-arc-x86-sgi.diff You'll need to install devel/mingw32-binutils. Regards BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: natd + ipfw question
On Tue, Dec 23, 2003 at 11:54:39AM -0500, Leo Bicknell wrote: doesn't? Yes, I want to do something fancier treating inbound and outbound traffic differently, but this basic case doesn't seem to work, and it seems to me like it should. What am I missing? Have you configured IPFW2 (if running 4.x) into the kernel and rebuilt the appropriate pieces of world? BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adding more ram
On Wed, Dec 10, 2003 at 09:41:11AM -0500, Bill Vermillion wrote: Systems such as the Irix I used before moving the servers to FBSD around 1996 - reserverd swap space for applications when the application started up so those needed large swap space. Often it was never used, but the design allocated it anyway. I also remember what fun could be had on an IRIX 5.3 machine with leaky X11 servers. SGI's Xsgi memory leaks on that IRIX release were particularly noticeable when using it on a 24-bit Indy and viewing lots of porn^Wgraphics. This seemed to be down to Xsgi reserving lots of swap in lieu of a heavy backing store workload, which it didn't actually use. And this often brought Xsgi crashing to a halt anyway. So I would have mixed feelings about adopting such a scheme in future. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ifconfig(8) refactoring -- YACC grammar now online
Hi all, As per Sam's suggestion, I've been working on refactoring ifconfig(8), which has grown increasingly large and unwieldy. Part of the effort has been to get a handle on all of the options we currently support; so I've written a YACC grammar for it. This is my first serious bit of work with YACC so I'd appreciate any feedback you can give. I've uploaded the grammar, makefile, and all the EPS files, here:- http://people.freebsd.org/~bms/dump/nifconfig/ (for browsing) http://people.freebsd.org/~bms/dump/nifconfig.tgz (tarball) I've also generated a PDF file you can view which shows you syntax diagrams for each part of the parse tree. This is here:- http://people.freebsd.org/~bms/dump/nifconfig/all.pdf I can't quite seem to persuade Ebnf2ps to generate a recursive unfolding of all productions from argv downwards, though, that would be most helpful. This involved rolling two ports, epsmerge and Ebnf2ps, to visualize the syntax graphically. I will commit these ports once the freeze as over as they're likely to be useful to a lot of people. Please let me know your thoughts on this. Thanks, BMS pgp0.pgp Description: PGP signature
Re: ifconfig(8) refactoring -- YACC grammar now online
On Sun, Nov 30, 2003 at 01:12:42PM +0100, Andre Oppermann wrote: What I've thinking about a lot is to make the networking system and ifconfig sort of class-based like newbus and geom. Look at: http://people.freebsd.org/~bms/dump/nifconfig/nifconfig-design.txt There is a pending change to if_gre to enable it to be easily classified in this way; ifconfig would simply query the interface for its if_type. This is one way to do it without having to change struct ifnet. We could add a new field, but avoiding changing the ABI is a Good Thing. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ifconfig(8) refactoring -- YACC grammar now online
On Sun, Nov 30, 2003 at 02:20:50PM -0500, Robert Watson wrote: if_type seems like it will work for high level classes of interfaces, but something more fine-grained will be required for interfaces that implement multiple classes or subclasses (i.e., 802 generally, and also 802.11b). The idea just now is we look at if_media if we need to get specific with physical interfaces. tap would seem to be missing from my list, actually; I note it's used to provide VMware support in the absence of Netgraph, amongst other things. Or likewise, tap interfaces might implement 802 generally, but also if_tap-specific primitives. Do we need to probe by-name for capabilities using interface ioctls, or return a list of implemented interfaces/classes to allow things to be a bit more multidimensional? That might work well, actually -- I already added a MIB to rtsock to deal with our lack of reporting multicast group memberships, I see no reason not to add one to enumerate loaded interface classes. OTOH, for the 'could load kld' case, this falls down, until the instance is created, either through cloning or completing ifattach() for a physical interface -- but if CREATE is a separate operation this isn't a problem, it is a problem if we want to say something like this in one go:- ifconfig gif0 create tunnel 1.2.3.4 5.6.7.8 10.0.0.1 10.0.0.2 Then you do need a means for the ifconfig instance to ask gif0 if it speaks 'tunnel-ese' once it's loaded. I have to find an abstraction to comfortably deal with this stacking of properties/methods, simple polymorphism (a la Java 'implements interface') springs to mind. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Making a FreeBSD DVD
On Sun, Nov 23, 2003 at 09:28:37PM -0500, Leo Bicknell wrote: I'd like to make my own distribution DVD's. I know how to make [snip] I'm intrigued by this. Is it possible to build DVDs which will boot on i386 and/or a variety of architectures? FAQ pointers welcome... BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Conflict between sys/sysproto.h stdio.h ... ?
On Tue, Nov 18, 2003 at 12:39:37AM -0800, lucy loo wrote: I am writing a kernel loadable module to reimplement some system calls. I have included sys/sysproto.h, sys/systm.h, etc. -- very standard header files for kld implmentation. I also want to do file i/o in this module, therefore I need to include stdio.h. But it obviously conflicts with those sys/..., and make won't pass. RTFM - particularly style(9), do not include userland headers in the kernel. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On Tue, Nov 18, 2003 at 04:31:32PM -0800, Rayson Ho wrote: I am wondering if it is useful to have a secure file flag?? ... e.g. when deleting a secure file, the OS will overwrite the file with random data. I've got patches somewhere for zeroing out memory mappings in this way, but they are incomplete. :-( BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Driver question
Craig, On Sat, Nov 08, 2003 at 10:11:22PM -0500, Craig StJean wrote: I have a prism2 USB wireless device. I've never written drivers before but I have been developing for the past 8 years. Could someone guide me to a website or something that would help me write a USB wrapper for the wi device? I have a copy of the old uwi driver which is now broken so it may help me along the way aswell. I'd suggest co-ordinating your efforts with Stuart Walsh who wrote the atwi USB driver. This is for atmel USB parts, but there are certain devices with the same VID/PIDs which are prism2 USB devices. His code might serve as a good starting point for you. Regards, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel malloc usage
On Mon, Nov 03, 2003 at 10:51:58AM +0100, Gerald Heinig wrote: Is this true? I seem to remember that FreeBSD has a slab allocator, which IIRC is particularly good at allocating small chunks. You don't specify which version of the kernel you're programming to; so I'll assume 5.x. If your allocations are of similar size, then consider using the zone allocator; I believe this implements a slab-like algorithm. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
User asks: can we decouple device vendor IDs from drivers?
Hi,
This sounds like one for the NEWBUS people.
BMS
---BeginMessage---
In message [EMAIL PROTECTED], Bruce M Simpson wrote:
Hiya
To follow up what I said down the pub...
The file in solaris i was referring to is called /etc/driver_aliases
do a search to find out about it.
Looking at the mess in FreeBSD device drivers and how the drivers
decide to attach to a device or not, then a lot of effort would
be needed to clean those up, but should an alias file such as the
solaris one exist in FBSD, IMHO it would make the life of everyone
much easier.
Perhaps you should look into it and propose to the FBSD team about
implementing something sane like this, hacking every driver to
add a new device ID is really a pain.
Cya
--
// /
{:)==={ Darron Broad [EMAIL PROTECTED]
\\ \
---End Message---
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some mmap observations compared to Linux 2.6/OpenBSD
On Wed, Oct 22, 2003 at 09:40:44AM -0500, Dan Nelson wrote: The actual commit quote reads: use a red-black tree to find entries in the vm_map. augment the red-black tree to find free space between entries. speeds up memory allocation, etc... I am wondering if there is a compelling reason why the technique used by OpenBSD could not be adapted to FreeBSD's VM system. Probably just a case of too much to do and not enough people to do it. FreeBSD already has sys/tree.h, which provides the red-black tree macros. Now accepting patches! BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sshd source code
On Fri, Oct 17, 2003 at 03:58:33PM -0700, Tim Kientzle wrote: Assuming, of course, that they don't ever turn their machine off. If they do, then 'locate' is just a waste of disk space. Or install the anacron port. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why is PCE not set in CR4?
On Wed, Oct 01, 2003 at 11:39:36AM +0200, Grumble wrote: I have read the perfmon documentation and source code. For several reasons, I do not think it is totally adequate in my situation. It was designed in 1996 with the Pentium Pro in mind, which, apparently, only has two performance counters: #define NPMC 2 if (pmc 0 || pmc = NPMC) return EINVAL; [..] Assume I get perfmon to work with my K7's 4 performance-monitoring counters. Since PCE is not set, I am not allowed to call RDPMC from ring 3. I have to make a system call, just to read the counters. I've since read over perfmon and some notes on using performance monitoring counters in The Indispensable PC Hardware Book. It looks to me as though perfmon *will* do what you want. There isn't really any need to reinvent the wheel. If you want to configure *all* your PMCs to read particular events, then the best way to do this is as follows: Conditionalise the PMC allocation code in perfmon.c to use a boot-time tunable, or an int, which is set by the identcpu.c code. Allocate the PMC structures in perfmon.c at boot-time (or preferably module init time). Then, add the necessary code to perfmon_init() and a new writectlXX() function pertaining to the particular Athlon you're using. I will pay in terms of computation overhead to process a system call, instead of a single instruction. But more importantly, it will wreck the cache, and possibly the TLB. There is no point in monitoring an event if the monitoring tools disturb the environment too much. Ignore the patch I sent previously. perfmon is i386 specific anyway, so hacking perfmon.c is acceptable. What I would suggest instead is to add two new ioctls to perfmon to do this. PMIOGPCE get pce bit value on current CPU PMIOSPCE set pce bit value on current CPU (if superuser) This will allow you to set PMC enable on and off for the uniprocessor case OK, and let you use RDPMC from ring 3. This is not valid for the SMP case, however. Unless you can achieve CPU binding (not affinity) with one of the current scheduler(s) then reading the counters is likely to yield useless results if your code spins across CPUs in an SMP system. An IPI of some kind will be necessary if you want to tell all processors to turn on their PCE bit at the same time. [EMAIL PROTECTED] is a good guy to ask about this sort of thing. I'd like to know how you're progressing with this. BMS pgp0.pgp Description: PGP signature
Re: boot0 screen output with dual-boot of FreeBSD / WinXP
On Fri, Oct 17, 2003 at 01:25:04PM +0930, Daniel O'Connor wrote: Basically, no. There is no room left in boot0 :( I think you could do it by squeezing down some text strings, and removing other [less common] entries though. That's what I had to do when I special-cased it for serial console support. If there's sufficient demand we could resurrect the 1024-byte boot0, but call it something else. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: to write a device driver or not to write (i/o, opl3, stupidity)
I mean, what services do drivers offer? What services they _need_ to offer? Do they just create appropriate device nodes and let the applications to worry about using them or do they do some data manipulation or do they offer routines and interfaces for applications or what? What should this particular driver do as I just want to read/write data. I think for your application running in userland is fine, if kernel programming is likely to be a steep learning curve. You can use nanosleep() to get the timing you need. On Wed, Oct 15, 2003 at 05:13:29PM -0400, Mathew Kanner wrote: I'm not positive about this but I think that you can do it from usermode by opening /dev/io (as root) and the use inb, outb macros defined in cpufunc.h. You can also use i386_get_ioperm() and i386_set_ioperm(). These change the I/O port permission bitmap in the process's Task State Segment (TSS) accordingly, so that you can issue IN/OUT instructions without segfaulting in a similar way to opening /dev/io. The only trouble with /dev/io is that it's an all-or-nothing approach (processes literally can write anywhere in I/O space); better to ask for what you need than ask for everything, IMHO. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: afaapps port committed to FreeBSD
On Mon, Oct 13, 2003 at 05:20:31PM +0200, Helge Oldach wrote: I may sound ignorant, but what is wrong with the FreeBSD-native aaccli utility that can be downloaded from Adaptec (5400s_fbsd_cli_v10.zip)? I have been using this for some time now with success. May I suggest to make a port out of this as well? Already did. Didn't realize til after scottl@ told me the next day. Check [EMAIL PROTECTED] :-) BMS pgp0.pgp Description: PGP signature
Re: Determining CPU features / cache organization from userland
All, Here are detailed design documents for determining cache and TLB geometry across our currently supported processor architectures, with recommendations outlined for implementation. What I haven't addressed yet is how indirect consumers of the API might use it, e.g. mutex consumers vs. UMA, in the context of allocating cache-aligned mutexes from a mutex pool. Please let me know your thoughts. BMS Detailed design for cache/tlb geometry discovery all --- Review NetBSD's uvm_page_recolor() viz applicability to FreeBSD VM/UMA. alpha - Action: Add code to machdep.c in identifycpu() to fill out hw_cacheinfo. Cache discovery: Static tables keyed on specific CPU model. TLB discovery: Static tables keyed on specific CPU model. Cache heuristic: 8Kb L1 Split Direct Mapped (21064) 2MB L2 Unified Direct Mapped (21064) All CPUs below 21264 have a 32-byte L1 line size. 21264 (EV6) has a 64-byte L1 line size. Optional L3 cache. TLB heuristic: ITLB 8KB page 8 lines, 4MB page 4 lines (21064) DTLB 32 lines, all page sizes, fully associative. (21064) ia64 Action: Add code to machdep.c in identifycpu() to fill out hw_cacheinfo. Review Linux's pal.h and palinfo.c. files. Cache discovery: Call the platform functions PAL_CACHE_SUMMARY and PAL_CACHE_INFO to get this information. TLB discovery: Static tables keyed on specific CPU model. Cache heuristic: L1 typically split 4-way set-associative 16KB, L2 256KB unified, L3 3MB-6MB unified. Line size isn't defined by the architecture. TLB heuristic: L1 TLB, split, data/instruction 32 entries each, fully associative L2 TLB, split, data/instruction 128 entries each, fully associative i386 pc98 amd64 --- Action: Add code to identcpu.c to fill out hw_cacheinfo. Cache discovery: Extended CPUID. Static tables if 486-class machine. No cache on 386. TLB discovery: Extended CPUID. Static tables if 486-class machine. No cache on 386. Cache heuristic (Intel): L1: 4-way, 32 bytes/line Cache heuristic (AMD): L2: 8-way, 64 bytes/line TLB heuristic (Intel): 4KB Code: 32 entries, 4-way, LRU 4MB Code: 2 entries, Fully associative, LRU 4KB Data: 64 entries, 4-way, LRU 4MB Data: 8 entries, 4-way, LRU TLB heuristic (AMD): 4KB L1 Code: 16 entries, Fully associative, LRU 4MB/2MB L1 Code: 8 entries, Fully associative, LRU 4KB L1 Data: 24/32 entries, Fully associative, LRU 4MB/2MB L1 Data: 8 entries, 4-way, LRU 4KB L2 Code: 256 entries, 4-way, LRU 4KB L2 Data: 256 entries, 4-way, LRU (That's 6 distinct TLBs to deal with on AMD-based i386 architectures). powerpc --- Action: Adapt from NetBSD as appropriate. Cache discovery: Open Firmware on CHRP if available. Static tables keyed on specific CPU model. TLB discovery: Open Firmware on CHRP if available. Static tables keyed on specific CPU model. Cache heuristic: L1 line size: 32 bytes across family. Pre-G5: 32KB/32KB Split, 8-way G5: 64KB/32KB Split, 1-way L2 line size: 32/64/128 bytes, TLB heuristic: PPC 601e: 4KB Instruction TLB, 4 entries, most recently used translations UTLB, 256 entries, 2-way set associative, software selectable block size OFW properties: i-cache-size i-cache-sets i-cache-block-size d-cache-size d-cache-sets d-cache-block-size tlb-size tlb-sets l2-cache [*] CHRP only mips Action: Adapt from NetBSD as appropriate. Cache discovery: Static tables keyed on specific CPU model. TLB discovery: MIPS32/MIPS64 Privileged Resource Architecture registers Cache heuristic: Split/unified L1/L2, unified L3. TLB heuristic: 16KB page size, 64 entries, fully associative (R1) sparc64 --- Action: Adapt existing code in cache.c to fill out and use hw_cacheinfo. Review assembly code, particularly that which abuses the TLB. Work closely with jake@ to avoid code churn. Cache discovery: Open Firmware. TLB discovery: Open Firmware. Cache heuristic: Split L1, Unified L2. TLB heuristic: Split L1 TLB. Fully Associative. NLU. 64 lines each. OFW properties: icache-size icache-line-size icache-associativity dcache-size dcache-line-size dcache-associativity ecache-size ecache-line-size ecache-associativity #dtlb-entries #itlb-entries Maintain information about cache and TLB geometry in an MI structure. The abstraction is intended to reflect current and future machine architectures. It is expected that the contents of these structures may not change over the lifetime of the kernel. Keeping this information in a structure doesn't significantly increase the cost of retrieving it from userland anyway. Userland consumers such as thread libraries and memory allocators should take a copy of this structure upon initialization. Kernel consumers may feel free to cache the information in local variables as they like. TLBs are 'caches' for virtual address lookups. Like data and instruction caches, they may employ set associativity to reduce the risk of unnecessary cache flushes/misses in multiprogramming
Re: Determining CPU features / cache organization from userland
All, I came up with the attached text file today to summarize some of my findings, after looking at various open source trees to see how they handle run-time cache geometry detection. Many will find it ironic that i386 is the easiest platform to deal with. [ Andrew: Perhaps you can shed some light on how the necessary information can be gathered on Alpha? My search was incomplete and I could not find a reliable source for DEC's development manuals. ] Jeff Roberson suggested I adopt NetBSD's API, however, on further examination it's clear that NetBSD's approach isn't consistent across all platforms. Darwin takes a similar approach, but it is perhaps too PowerPC-centric. sysctl is a good interface for retrieving this information as it doesn't change during the lifetime of the kernel, and it is small. sysctl is already invoked from within libc to retrieve information in this way. glibc's approach to dealing with situations where knowledge of the cache line size is needed is a bit fractious - it retrieves the information from an 'aux vector' passed to glibc at startup. I think threading libraries should seriously consider becoming consumers of the API once it's finalized. Mutex alignment on cache line boundaries is desirable for userland applications too. However, phk malloc would need to be changed in order to support this specific form of aligned allocation. Perhaps a separate pool or zone could be used for this kind of allocation? This becomes more important and timely when one considers the I/O alignment restrictions we've encountered. Some applications may need to align their buffers on arbitrary boundaries to suit devices, too. BMS all --- NetBSD cache information API(s) are not consistent across platforms. alpha - Cache discovery? Static. 21064, 21064A, 21066, 21066A, 21164 all have line sizes of 32-bytes. The 21264 has a 64-byte line size. 21364: L1 split, 64KB each, 2-way set-associative, Virtual caches can be implemented using PALcode, but this is probably more of a curiosity than anything else. ia64 Cache discovery? Call PAL_CACHE_INFO, I think. No documentation on how to do this at this time. I have emailed [EMAIL PROTECTED] asking for advice. i386 pc98 amd64 --- Cache discovery? CPUID. Earlier chips which don't support it probably don't have a cache, or aren't worth supporting. General rule for x86: split L1, unified L2, optional unified L3. General rule for Intel P5: 2-way, 32 bytes/line General rule for Intel MMX and up: 4-way, 32 bytes/line PPro doesn't have L3. The newer cores have different cache geometry. powerpc --- Cache line discovery? Static. Many core variants. I have not seen any runtime code for this. The POWER clcs instruction is obsolete. OpenDarwin assumes 32-bytes. It has hooks for discovering the cache geometry at runtime but these are not used. NetBSD statically initializes this information according to the discovered CPU model in use, which is the way to go. NetBSD tells uvm to recolor the page queues if required. Linux uses static #define's from IBM people, except in the case of ppc64, which is strikingly similar to the OpenDarwin code except it actually talks to the open firmware. Open Firmware on CHRP should however provide the following for each cpu device node configured in the system: i-cache-size i-cache-sets i-cache-block-size d-cache-size d-cache-sets d-cache-block-size tlb-size tlb-sets l2-cache All are integers except for l2-cache which is the address of an l2-cache device node if the system found one. mips The NetBSD MIPS code for dealing with cache geometry was recently updated. MIPS caches may be split/unified at L1/L2 and unified at L3. Cache detection code is quite voluminous. Swipe NetBSD's if FreeBSD/mips ever kicks off. Many, many core variants. sparc64 --- Cache line discovery? Performed by Open Firmware. Open Firmware property names used are ever so slightly different from Apple's. icache-size icache-line-size icache-associativity dcache-size dcache-line-size dcache-associativity ecache-size ecache-line-size ecache-associativity Already handled within cache.c, but assembly stubs *expect* this information in a certain format. Specifically they need to see the data cache/instruction cache sizes and line sizes. General rule: Split L1, Unified L2. Cores: Spitfire/Blackbird/Cheetah ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dynamic reads without locking.
On Fri, Oct 10, 2003 at 10:31:21PM -0700, Tim Kientzle wrote: On further inspection, I'm pretty sure that sys/kern/subr_devstat.c is not correct. OK. What about the shared page interface? Specifically the comment above devstat_end_transaction(). The generation count is used by the old sysctl interface. The shared page interface has a liberal sprinkling of atomic*() instructions. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Determining CPU features / cache organization from userland
On Sat, Oct 11, 2003 at 01:58:27PM +1000, Peter Jeremy wrote: If you do this, it may make sense to use the same names as MacOSX. What if your hardware has different linesizes for different caches? I noticed whilst peering in Apple Developer Notes that G5 has 128 byte cache line size, and this screws up mutexes bigtime. (!!) OS X definitions considered too PowerPC centric. I think the best way to handle all cases is thus:- - Support 3 levels of cache. - Each level may be unified or split between code and data not-quite-Von-Neumann-style. - Allow explicit retrieval of this info keyed on the cache you're interested in. This means: hw.cache.lN.(linesize|lines|sets) - Do similar for the TLB insofar as we can return information about the chip's TLB. I know for example from talking to peter@ that the Opteron is quite a different beast (ASNs, flush filter, etc). - Assume that all CPUs have identical characteristics in an SMP system. Trying to assume otherwise is pointless. People should be using matched chips anyway. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: smallest piece of hardware that runs *BSD?
On Fri, Oct 10, 2003 at 07:37:23PM -0700, Wes Peters wrote: Grab a copy of Embedded Systems Programming, there are ads for things like this all over near the back of the magazine. In particular, the chip in whatever USB stick you're looking at probably has an 8-bit CPU of some sort in it. I find Circuit Cellar is also a good periodical for stuff like this! BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
