Re: Darwin/OSX Bluetooth code
If you don't find it on the darwin site (http://developer.apple.com/darwin), it's probably not going to show up as an open source project. Regards, Justin On Thursday, October 16, 2003, at 09:00 PM, Maksim Yevmenkin wrote: Dear Hackers, Does anyone know if Apple has released Darwin/OSX Bluetooth code to the public? Quick look at http://www.opensource.apple.com/ did not reveal anything particularly useful (although i did not try really hard :) I'm currently thinking about un-Netgraph'ing FreeBSD code to make it portable to other BSD style systems. I'm trying to look at other implementations and learn as much as i can. In particular i'm trying to figure out how to minimize OS dependent code and what is the right abstractions levels. thanks, max __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics| If you're not confused, | You're not paying attention *--*---* ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbuf doubts
I'm not an expert on all BSD-derived stacks and the way mbufs are defined and used in each, but: On Tuesday, September 23, 2003, at 07:12 PM, Giovanni P. Tirloni wrote: struct mbuf *m; 1. Normal mbuf using m-M_databuf M_databuf is the beginning of the data area in an mbuf 2. Normal mbuf with external storage (cluster?) in m-m_hdr-mh_data mh_data *always* points to the beginning of valid data or available space. The bit M_EXT indicates whether mh_data points into the external storage, or into the area beginning at M_databuf. 3. Header mbuf using m-m_pktdat; This is used to access the data in an mbuf when the M_PKTHDR bit is set in the m_flags word. This is because extra space in this lead mbuf is taken up with local information pertaining to the packet and its handling. I'm not entirely clear on how it's used. 4. Header mbuf with ext. storage (cluster?) in m-m_ext-ext_buf This points to the external storage buffer. It can be a cluster, or it can be other data areas. I believe the distinction is made based on the field ext_free in the m_ext structure (if non-null, it points to a routine to free data, and thus the external storage is *not* a cluster). Other questions: 1. When using ext. storage is the space allocated by M_databuf wasted? Yes. 2. How the system decides 256 bytes for each mbuf isn't enough and it needs a mbuf cluster? Isn't chaining useful there? There is a constant (MINCLSIZE) that the system uses to decide when to allocate a cluster, and when to use a chain of normal mbufs. If the size is greater than MINCLSIZE, it opts for a cluster. Note that you can sometimes notice the effect of MINCLSIZE on the performance of both the system and the network, so the choice of this value can be important. It is normally set to a value that goes to clusters when two mbufs won't suffice. 3. How does changing MSIZE affects the whole thing? Significantly :-}. This is a gnarly subject. You have to balance wasted space, time, and other subtle details (typical packet sizes vs. mbuf size; time spent dealing with chains vs. time spent dealing with clusters; ...). At one point, for example, packet sizes on the internet were strongly bi-modal (small packets for telnet; max-sized packets for ftp). More recently, I suspect that this has changed, but I don't know what the distribution looks like now. 4. What about MCLBYTES? Same set of issues. AIX, for example, has a power-of-2 collection of mbuf pools, and tries to allocate from the best pool for the requested size, bumping up at most two levels to fill empty pools. Other BSDs stick with a single size, generally 2048 bytes; this makes jumbo ethernet packets kind of expensive. Check out Wright/Stevens, TCP/IP Illustrated, V.2, Addison Wesley, 1995. Ch. 2 is a fairly in-depth discussion of the above. It deals with a long-dead version of BSD, but the fundamentals have not changed that much. In addition, the book is a very well-done code walkthrough of the networking code in BSD (again, from long ago, but the bones are good). Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics| It's not whether you win or lose... | It's whether *I* win or lose. *--*---* ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: C++ code in a kernel module?
On Tuesday, September 9, 2003, at 08:58 AM, John Giacomoni wrote: On Tuesday, Sep 9, 2003, at 00:29 America/Denver, Peter Jeremy wrote: On Mon, Sep 08, 2003 at 11:12:59PM -0400, Alexander Kabaev wrote: On Mon, 8 Sep 2003 23:02:33 -0400 Matthew Emmerton [EMAIL PROTECTED] wrote: [snip] simple, I have preexisting C++ code which we are currently using in userland and wish to push down into the kernel. It would be ideal to keep the source bases the same without a rewrite to C. Admitting of course the possibility of having to modify to be compatible with both use modes. At present I am attempting to see what we can and cannot do in the kernel with C++ FWIW, Darwin (the underpinnings for Mac OS X) uses C++ for its device drivers. This is done by hewing to a model roughly that of Embedded C++, compiling statically, and having a separate library that differs from libstdc++ in significant ways. Getting this to work well was non-trivial, but it does work (sadly :-}). If you are trying to get user-mode code to work in the kernel, you are in for an enjoyable year... You can check Apple's Darwin site for available doc (http://developer.apple.com/darwin). The code is available under Apple's open source license (APSL 2.0). Regards, Justin -- /~\ The ASCII Justin C. Walker, Curmudgeon-at-Large \ / Ribbon Campaign X Help cure HTML Email / \ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mac iBook OS10 + BSD
On Sunday, December 22, 2002, at 10:24 PM, Steve Kudlak wrote: David Hunt wrote: I have been using Linux (Slackware) for a number of years on my desktop, and have never used BSD. From what I've gathered, BSD sounds like the kind of OS I would like. [snip] This brings up an interesting question. Apple makes all sorts of noises about BSD being the basis of the MAC. FreeBSD 4.4 has, more or less, been integrated with the Darwin/Mac OS X kernel for the 10.2/Jaguar release. It's a real Unix under all the colors. You can get at it with ease, using Terminal, or remotely via ssh/rlogin/telnet. Keep in mind that because there's a serious commercial product around it, and the heritage includes NeXT, it's not identically FreeBSD. The very low layers are Mach-based, which accounts for some differences. The networking is BSD-based, and incorporates much of FreeBSD 4.4, but is not entirely compatible. None of this should bother you if you are not deep into kernel development. If I get the bucks I may switch to a MAC. My question is how much of the BSD operating system can one get access to on a MAC running OS X? You can get at all of the low-level OS. As above, it's not identical to any flavor of BSD. Has anyone done even simple things like started up cron jobs Yup. and the like to do housekeeping? Most of the MAC users I know, know BSD is there but haven't done much with it. IN fact there are noises one can't get at all the internals and the like. Noises abound, but as is generally the case, the more noise, the less information. Does anyone have any details about all of this stuff. I know this is kind of general question to post on this list. But so far even lurking this list is often where real questions often get answered. Any pointers would be appreciated. You can lurk on the 'darwin' lists (http://lists.apple.com) for discussions of low-level stuff, as well as kernel extension and driver development. Try the lists at http://www.omnigroup.com for discussions dealing with the management of Mac OS X systems. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics| If you're not confused, | You're not paying attention *--*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel Debugging over the Ethernet?
The Apple darwin site is: http://www.opensource.apple.com I've not looked through the source for this, so you may have to inquire on the darwin-development mailing list for pointers into the source repository. Regards, Justin On Thursday, February 21, 2002, at 07:48 AM, Andrew Gallatin wrote: Justin C.Walker writes: On Wednesday, February 20, 2002, at 04:52 PM, Julian Elischer wrote: yes but we might as well be protocol compatible if possible :-) If only to re-use what they did in gdb :-) The Darwin/Mac OS X scheme only deals with IOKit because that's where the drivers live. The protocol implementation is in the directory 'xnu/osfmk/kdp'. It's in essence a UDP protocol, and is implemented without using any of the system's networking scheme (except for mbufs). The implementation is polling. The implementation is pretty light-weight. Where do the Darwin gdb sources live, so we can see the gdb end of it too? I've looked, but have so far been unable to find them. Thanks, Drew -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics|Men are from Earth. |Women are from Earth. | Deal with it. *--*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel Debugging over the Ethernet?
On Wednesday, February 20, 2002, at 04:52 PM, Julian Elischer wrote: yes but we might as well be protocol compatible if possible :-) If only to re-use what they did in gdb :-) The Darwin/Mac OS X scheme only deals with IOKit because that's where the drivers live. The protocol implementation is in the directory 'xnu/osfmk/kdp'. It's in essence a UDP protocol, and is implemented without using any of the system's networking scheme (except for mbufs). The implementation is polling. The implementation is pretty light-weight. Regards, Justin On Wed, 20 Feb 2002, George V. Neville-Neil wrote: I was talking to Louis Gerbarg about this topic at the BSDCon last week. Apparently Darwin already has this functionality, so I suppose you'd like to take a look at it. That depends on where they put it. If it depends on I/OKit then we won't be able to use it easily I figure. -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics| When LuteFisk is outlawed | Only outlaws will have | LuteFisk *--*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: USB device framework in FreeBSD 4.2
On Friday, February 8, 2002, at 01:51 PM, Srinivas Dharmasanam wrote: Nick, I'm trying to use a modified version of the ugen driver in FreeBSD 4.2 to control a USB device from the kernel space and am getting a kernel crash with a page fault trap (trap_fatal) when I try to do open on this device. From a user process, I am able to open this device with no problem but when I call the underlying open() function from an ISR (so that I get kernel mode), I get this fatal trap. The backtrace of the kernel core dump is pasted below. Note that the usbd_transfer() function in usbdi.c has the call tsleep() that is causing this trap. Can you please let me know how I would be able to access a USB device from the kernel space? Do I have to write another USB driver along with the usbdi.c interface or is there a way I can do this with the existing USB device framework? First, try [EMAIL PROTECTED], where the USB mavins tend to hang out. Next, be aware that the device driver model in Darwin and Mac OS X is significantly different from that in FreeBSD, so it won't be a simple matter to get this code working. Also, you don't want to call open() in the kernel, unless it is *really* necessary; if you do need to do this, which is unlikely, you should study the open() call in the kernel source to be sure you are obeying all the rules. In particular, *don't* call open() from an ISR. Finally, don't call tsleep() from an ISR. Oh, and the backtrace seems to have disappeared between the time you wrote the above and when you sent it. There are several USB components in the darwin repository; check them out and look at the code. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics| It's not whether you win or lose... | It's whether *I* win or lose. *--*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Fwd: USB device framework in FreeBSD 4.2
Forgive the inane chatter below. I have too many windows open, and my brain went to sleep before I did. Regards, Justin Begin forwarded message: From: Justin C.Walker [EMAIL PROTECTED] Date: Fri Feb 08, 2002 10:10:48 PM US/Pacific To: [EMAIL PROTECTED] Subject: Re: USB device framework in FreeBSD 4.2 On Friday, February 8, 2002, at 01:51 PM, Srinivas Dharmasanam wrote: Nick, I'm trying to use a modified version of the ugen driver in FreeBSD 4.2 to control a USB device from the kernel space and am getting a kernel crash with a page fault trap (trap_fatal) when I try to do open on this device. From a user process, I am able to open this device with no problem but when I call the underlying open() function from an ISR (so that I get kernel mode), I get this fatal trap. The backtrace of the kernel core dump is pasted below. Note that the usbd_transfer() function in usbdi.c has the call tsleep() that is causing this trap. Can you please let me know how I would be able to access a USB device from the kernel space? Do I have to write another USB driver along with the usbdi.c interface or is there a way I can do this with the existing USB device framework? First, try [EMAIL PROTECTED], where the USB mavins tend to hang out. Next, be aware that the device driver model in Darwin and Mac OS X is significantly different from that in FreeBSD, so it won't be a simple matter to get this code working. Also, you don't want to call open() in the kernel, unless it is *really* necessary; if you do need to do this, which is unlikely, you should study the open() call in the kernel source to be sure you are obeying all the rules. In particular, *don't* call open() from an ISR. Finally, don't call tsleep() from an ISR. Oh, and the backtrace seems to have disappeared between the time you wrote the above and when you sent it. There are several USB components in the darwin repository; check them out and look at the code. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics| It's not whether you win or lose... | It's whether *I* win or lose. *--*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics|Men are from Earth. |Women are from Earth. | Deal with it. *--*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: OS Textbook FreeBSD Appendix
On Monday, January 28, 2002, at 02:49 PM, Ronald G Minnich wrote: On Mon, 28 Jan 2002, DOROVSKOY,IGOR (A-Portsmouth,ex1) wrote: I've took a brief look on Unix presentation and was wondering, why author says that ...most Unix systems have not permitted shared memory because the PDP-11 hardware did not encourage it...? where'd they get this? that's an odd statement. Shared memory was used all the time on Unix on -11s, that's the whole point of the shared text a.out format. Of course shared read-only text is not exactly the standard shared memory, but at the same time it shows feasibility. The address space was so small though that other mechanisms were used. I'd guess that the point deals with the use of shared memory between processes for the purposes of sharing data. Given the granularity of the PDP-11 VM hardware, it seemed like a bad tradeoff, and wasn't considered useful until long after the PDP-11 went to the Boston Computer Museum, where it sipped tea and complained about the Red Sox. Regards, Justin -- /~\ The ASCII Justin C. Walker, Curmudgeon-at-Large \ / Ribbon Campaign X Help cure HTML Email / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: OS Textbook FreeBSD Appendix
On Monday, January 28, 2002, at 05:10 PM, Greg Shenaut wrote: In message [EMAIL PROTECTED], Justin C.Walker cleopede: I've took a brief look on Unix presentation and was wondering, why author says that ...most Unix systems have not permitted shared memory because the PDP-11 hardware did not encourage it...? where'd they get this? that's an odd statement. Shared memory was used all the time on Unix on -11s, that's the whole point of the shared text a.out format. Of course shared read-only text is not exactly the standard shared memory, but at the same time it shows feasibility. The address space was so small though that other mechanisms were used. I'd guess that the point deals with the use of shared memory between processes for the purposes of sharing data. Given the granularity of the PDP-11 VM hardware, it seemed like a bad tradeoff, and wasn't considered useful until long after the PDP-11 went to the Boston Computer Museum, where it sipped tea and complained about the Red Sox. Well, on PDP11s, which I used for V6, V7, and 2.8 2.9 BSD, you could share text memory, as has already been stated, and IIRC you could also share data memory after a vfork (once vfork became available on 2.9). It seems to me that I actually used the vfork memory sharing trick for some kind of primitive multithreaded program at one point. I think the limitation was that you couldn't map a small piece of memory share it among processes, only all text or all data, but I admit my memory is almost gone, and I don't remember PDP/11 architecture all that well either. You're correct; that's what I meant by the 'granularity' of the hardware. You had to share a fairly hefty chunk of memory, so (except for vfork-like-things), it put too much of a constraint on the use of the sharing. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics|Men are from Earth. |Women are from Earth. | Deal with it. *--*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Routing Socket and New Addresses
On Monday, January 28, 2002, at 05:03 PM, Andrew wrote: On Sun, 27 Jan 2002, Justin C.Walker wrote: It is and it is :-}. At least, Stevens discusses it in Unix Network Programming, v1, 2e (sec. 20.3). Different systems, alas, treat this case differently. My section 20.3 is on UDP Datagram Trunctation...did you mean 17.3 (Routing Sockets: Reading and Writing). I can't find any mention of this behaviour in either place mind you. Maybe I misunderstood the original message; I thought this thread dealt with the observed truncation of packets when read from a socket. 20.3 was what I intended, as it covers the observed behavior (at least, that's my story, and I'm sticking with it :-]). Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics| If you're not confused, | You're not paying attention *--*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Routing Socket and New Addresses
On Sunday, January 27, 2002, at 08:03 AM, Andrew wrote: On Sun, 27 Jan 2002, Andrew wrote: but it seems that if I don't read the packet with one read call then the packet is lost. Is this correct behaviour? I guess if the buffer is small Well it seems that if you dont get the entire packet in one read it is lost forever. It also seems that no matter how many bytes you try and read you only ever get one packet (though I haven't confirmed that for sure). If this is how it really works then perhaps it should be documented somewhere. It is and it is :-}. At least, Stevens discusses it in Unix Network Programming, v1, 2e (sec. 20.3). Different systems, alas, treat this case differently. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics|Men are from Earth. |Women are from Earth. | Deal with it. *--*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: interesting open() issue
My first guess is that the 'umask' differs in your various systems.
man 2 umask.
Regards,
Justin
On Wednesday, January 16, 2002, at 01:59 AM, Foldi Tamas wrote:
Hello hackers,
I tried the following program on Tru64, FreeBSD and linux:
#include stdio.h
#include fcntl.h
#include sys/stat.h
#include sys/types.h
main() {
int fd;
fd = open ( /tmp/foobar, (O_RDWR | O_CREAT), 0020);
perror(open);
close(fd);
}
The program ran successfully, but the created file was different.
On Linux:
-w1 crow crow0 Jan 16 10:32 /tmp/foobar
On Tru64/FreeBSD:
--1 crow users 0 Jan 16 10:30 /tmp/foobar
I'm not sure what the result supposed to be. Any ideas ?
Best Regards,
Tamas Foldi
--
/~\ The ASCII Justin C. Walker, Curmudgeon-at-Large
\ / Ribbon Campaign
X Against HTML
/ \ Email
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: The Hurd
On Tuesday, January 1, 2002, at 12:31 PM, Miguel Mendez wrote: On Tuesday 01 January 2002 20:14, Rafter Man wrote: So my question is: Will FreeBSD take a good look at the Hurd? I tried the Hurd in 1999 and wasn't very impressed, just downloaded the H2 ISO but haven't tried it yet. The only thing that makes the Hurd look like Unix is the POSIX compat layer. The advantages of a microkernel vs (pseudo) monolothic are well known, as well as disadvantages. Of course I can't speak for the FreeBSD developers but IMHO there's very little, if anything, that can be taken from Hurd and imported into FreeBSD (or Unix in general). Yes, you can ran a BSD server on top of Mach (MacOS X) but it's not the same as Hurd does. Just wanted to note: Mac OS X does *not* use this kind of OS. Its kernel is monolithic, in that all the pieces live together in the same address space, and communicate via procedure calls, not messages. Mach messaging can be, and sometimes is, used between processes, and between process and kernel [in some cases; BSD system calls are not turned into messages]. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics| It's not whether you win or lose... | It's whether *I* win or lose. *--*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Avoid Page swapping.
On Wednesday, May 31, 2000, at 06:15 AM, Alain Jourez wrote: Hi there, I beleive the sticky bit was used historically to prevent a whole process to be swapped. What is the precise meaning of it ? The 'sticky' bit was, historically, intended to keep an executable's swap image around after the last process using it exited. This behavior was an optimization in a time when reading a swap image was noticeably faster than performing an 'exec'. For its current meaning, try 'man sticky'. Regards, Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: one question:
From: Shadi Fazelian [EMAIL PROTECTED] Date: 2000-05-20 01:20:07 -0700 To: [EMAIL PROTECTED] Subject: one question: X-Loop: FreeBSD.ORG Delivered-to: [EMAIL PROTECTED] Hello and don't tire from destroying servers one question: in my server all of services is down(like ftp,telnet,) and in crontab there isn't somthing. but somebody can access to my server and can send e_mail In the /etc/rc* files you should find a line that starts 'sendmail'. That is likely the way that mail is delivered to your system. A "ps aux" will verify whether 'sendmail' is running. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Request for review (HW checksum patches)
From: Jonathan Lemon [EMAIL PROTECTED] Date: Sat, 25 Mar 2000 13:35:53 -0600 To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Request for review (HW checksum patches) X-Mailer: Mutt 1.0pre2i Delivered-to: [EMAIL PROTECTED] X-Loop: FreeBSD.org I have a set of patches which allows offloading checksums to NICs which support it (right now, only the Alteon based cards). The patch is at http://www.freebsd.org/~jlemon/csum.patch. This prompts a question on a related issue: there seems to be an increase in support of protocol operations on NICs (e.g., tickle/keep-alive support while the system is sleeping; IPSec; ...). Is there enough there to let us build a general mechanism for communication between stack and driver for this sort of thing (e.g., a "meta-data" slot in the packet header which points to an mbuf, or other structure, that contains the details)? We're currently trying to deal with this in Mac OS X, and it'd be nice to avoid having multiple wheels of different size and shape in the same source base. Regards, Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to get Ethernet MAC address
From: "Yevmenkin, Maksim N, CSCIO" [EMAIL PROTECTED] Date: 1999-12-03 10:11:49 -0800 To: "'[EMAIL PROTECTED]'" [EMAIL PROTECTED] Subject: How to get Ethernet MAC address Delivered-to: [EMAIL PROTECTED] X-Mailer: Internet Mail Service (5.5.2448.0) X-Loop: FreeBSD.ORG Hello All, Is there any ioctl command to get Ethernet MAC address from specific interface? I've checked netstat and ifconfig source code and mail archive. It seems to me all use different methods to do the same thing. I'm using FreeBSD 3.3-Release. May be SIOGHWADDR (as in Linux) is a good idea? Try SIOCGIFCONF, and search through the list of returned structures for one with address family AF_LINK. The sockaddr for this one will be a sockaddr_dl, with the MAC address enclosed. See the code, e.g., for netstat, or for ifconfig. There's also a sysctl() request that works. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ping - sized tests with 0% and 100% packet loss! Any ideas?
From: Peter Jeremy [EMAIL PROTECTED] Date: 1999-11-01 17:49:29 -0800 To: [EMAIL PROTECTED] Subject: Re: Ping - sized tests with 0% and 100% packet loss! Any ideas? Cc: [EMAIL PROTECTED] X-Mailer: Mutt 1.0pre3i Content-return: prohibited Delivered-to: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG At Tue, 2 Nov 1999 00:16:02 +, Josef Karthauser [EMAIL PROTECTED] wrote: Anyone any idea what's going on? The problem doesn't exist in 2.2.5-RELEASE. I can't readily test anything other than that and -current at present. FWIW, our kernel, based roughly on FreeBSD 3.2, has the same line as marked with "-", and I don't see the problem: # for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 do echo === $i === ping -f -c 300 -s $i localhost done| grep loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss 300 packets transmitted, 300 packets received, 0% packet loss Regards, Justin As far as I can determine, the problem with 1-byte packets is that the transmitted checksum is incorrect when the ICMP sequence number exceeds 255 - this suggests that the checksum missing the last byte of the sequence number. The problem is also on the transmit side. Studying the code in src/sys/netinet/ip_icmp.c:icmp_input() [which is reporting checksum errors] and icmp_send() [which inserts the checksum], it looks to me like the problem is: cvs diff: Diffing . Index: ip_icmp.c === RCS file: /home/CVSROOT/src/sys/netinet/ip_icmp.c,v retrieving revision 1.37 diff -u -r1.37 ip_icmp.c --- ip_icmp.c 1999/09/14 16:40:28 1.37 +++ ip_icmp.c 1999/11/02 01:45:34 @@ -685,7 +685,7 @@ m-m_len -= hlen; icp = mtod(m, struct icmp *); icp-icmp_cksum = 0; - icp-icmp_cksum = in_cksum(m, ip-ip_len - hlen); + icp-icmp_cksum = in_cksum(m, ip-ip_len); m-m_data -= hlen; m-m_len += hlen; m-m_pkthdr.rcvif = (struct ifnet *)0; though I can't confirm this immediately. (And I can't see why this would have worked at all). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbufs question/problem
From: Dennis [EMAIL PROTECTED] Date: 1999-06-30 15:24:46 +0200 To: [EMAIL PROTECTED] Subject: mbufs question/problem Delivered-to: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 X-Loop: FreeBSD.ORG Lines: 21 I have a customer who has been experiencing "slow downs" with a freebsd routerthey have substantially increased performance by reducing MINCLSIZE. I havent tracked the source, but im trying to hypothesize what it might be. On the surface I cant see any relationship since very few routines seem dependent on that value (m_devget() in particular, but I dont believe they are using any driver that use it). Is it possible that they are running out of small mbufs (they have NMBCLUSTERS set to a very high value)? The problem, I believe, is the cost of using multiple mbufs per packet when a packet exceeds MHLEN but is less than MINCLSIZE. Probably the best performance, at the expense of memory, is had by setting MINCLSIZE=MHLEN. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ping: sendto: Message too long
From: Krzysztof Krawczyk [EMAIL PROTECTED] Date: 1999-09-15 13:12:21 -0700 To: [EMAIL PROTECTED] Subject: ping: sendto: Message too long In-reply-to: [EMAIL PROTECTED] Delivered-to: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Hi, Could someone say me, why the maximum packetsize in ping command is 8184 (ping -s 8184)? If I want to do a bigger packetsize than this i got message like this: My guess: this is a "socket buffer size" issue. There should be two ways around this: - change the code to have 'ping' set its socket buffer sizes based on the requested size - use 'sysctl' to change the system's default send/receive buffer sizes (see net.inet.raw.maxdgram, net.inet.raw.recvspace). Naturally, I haven't tried this, or eyeballed the code, so treat this with some caution. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ping: sendto: Message too long
From: Krzysztof Krawczyk c...@denied.cx Date: 1999-09-15 13:12:21 -0700 To: hack...@freebsd.org Subject: ping: sendto: Message too long In-reply-to: pine.bsf.4.10.9909131744020.88005-100...@resnet.uoregon.edu Delivered-to: freebsd-hackers@freebsd.org X-Sender: c...@tepsa.lame.pl X-Loop: FreeBSD.ORG Hi, Could someone say me, why the maximum packetsize in ping command is 8184 (ping -s 8184)? If I want to do a bigger packetsize than this i got message like this: My guess: this is a socket buffer size issue. There should be two ways around this: - change the code to have 'ping' set its socket buffer sizes based on the requested size - use 'sysctl' to change the system's default send/receive buffer sizes (see net.inet.raw.maxdgram, net.inet.raw.recvspace). Naturally, I haven't tried this, or eyeballed the code, so treat this with some caution. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: message queues for I/O (usenix paper)
From: Garance A Drosihn [EMAIL PROTECTED] Date: 1999-09-09 10:33:59 -0700 To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: message queues for I/O (usenix paper) In-reply-to: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] At 6:44 PM -0700 9/8/99, Justin C. Walker wrote: From the FWIW department, we have, in the Darwin source, an implementation of a "select replacement" that is designed to get around some of the (perceived or real) issues with select(), e.g., looking at a long (FD_SETSIZE or larger) array of bits several times in the kernel and in user space. In the available sources, this is represented in sys/ev.h, and is implemented only for sockets. Our tests indicate a roughly 5-10% speed improvement when a lot of sockets are in use but not exuberantly so. This sounds like it will be interesting. If this works out, would it translate to the other *BSD's fairly easily? When you say "select replacement", do you mean select disappears from the system, or just that this will be an alternative to using select? We didn't do much to the existing code except to add the system calls, update some structures (proc and socket) with event record queues, and add the calls to do the work whereever an event was noticed. As long as other BSDs haven't changed these areas significantly, there should be little problem (it sez here...). One note: in order to make this fast, and to avoid resource problems during use, the event records are not dynamically allocated, and there's only one per event source. These are dynamically updated when on a queue, so you don't end up with allocation failures or really long queues. As for 'select()', we'd have to be crazy (:-}) to eliminate that call. After all, we want folks to port code into our system with relative ease. The call remains; the event scheme is an alternative for those that want to use it. Its use is intended to match that of select(), so that developers don't have to restructure existing code to use it. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: message queues for I/O (usenix paper)
From: Garance A Drosihn dro...@rpi.edu Date: 1999-09-09 10:33:59 -0700 To: jus...@apple.com, freebsd-hackers@FreeBSD.ORG Subject: Re: message queues for I/O (usenix paper) In-reply-to: 199909090144.saa02...@rhapture.apple.com X-Sender: dro...@mail.rpi.edu At 6:44 PM -0700 9/8/99, Justin C. Walker wrote: From the FWIW department, we have, in the Darwin source, an implementation of a select replacement that is designed to get around some of the (perceived or real) issues with select(), e.g., looking at a long (FD_SETSIZE or larger) array of bits several times in the kernel and in user space. In the available sources, this is represented in sys/ev.h, and is implemented only for sockets. Our tests indicate a roughly 5-10% speed improvement when a lot of sockets are in use but not exuberantly so. This sounds like it will be interesting. If this works out, would it translate to the other *BSD's fairly easily? When you say select replacement, do you mean select disappears from the system, or just that this will be an alternative to using select? We didn't do much to the existing code except to add the system calls, update some structures (proc and socket) with event record queues, and add the calls to do the work whereever an event was noticed. As long as other BSDs haven't changed these areas significantly, there should be little problem (it sez here...). One note: in order to make this fast, and to avoid resource problems during use, the event records are not dynamically allocated, and there's only one per event source. These are dynamically updated when on a queue, so you don't end up with allocation failures or really long queues. As for 'select()', we'd have to be crazy (:-}) to eliminate that call. After all, we want folks to port code into our system with relative ease. The call remains; the event scheme is an alternative for those that want to use it. Its use is intended to match that of select(), so that developers don't have to restructure existing code to use it. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: message queues for I/O (usenix paper)
From: Jayson Nordwick [EMAIL PROTECTED] Date: 1999-09-08 17:38:56 -0700 To: [EMAIL PROTECTED] Subject: message queues for I/O (usenix paper) Content-id: [EMAIL PROTECTED] Delivered-to: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG There is alot of talk going on over at the linux-kernel mailing list about implementing synchronous messaging for I/O. They are talking about a paper that was presented at USENIX: http://www.cs.rice.edu/~gaurav/papers/usenix99.ps The general idea is that select() and poll() fall over with large numbers of file descriptors for two reasons. First, scanning the interest list begins to consume more time. Second, the stateless nature between calls means that alot of redundant processing occurs. The solution these guys (the authors) say is to have a way of registering interest in descriptors, then you can call a procedure to find out what has changed since last time. I personally think that select() is just fine and can be implemented more efficiently than currently, but I would be willing to give it a shot at both cooperating with the Linux people to get a good Linux/FreeBSD API layed down and then implementing it. I know some of you heard this paper presented so does anybody have any ideas about it? Does anybody care? From the FWIW department, we have, in the Darwin source, an implementation of a "select replacement" that is designed to get around some of the (perceived or real) issues with select(), e.g., looking at a long (FD_SETSIZE or larger) array of bits several times in the kernel and in user space. In the available sources, this is represented in sys/ev.h, and is implemented only for sockets. Our tests indicate a roughly 5-10% speed improvement when a lot of sockets are in use but not exuberantly so. For Darwin in the future (the Core OS for Mac OS X), this scheme will be somewhat generalized, to provide a uniform mechanism for fielding events from any subsystem. It will be made more interesting by the need to incorporate mach message handling in addition to file-descriptor-based events. Have a look, should this be of interest. I'll be happy to field questions, since the doc is a bit, oh, scant... Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: message queues for I/O (usenix paper)
From: Jayson Nordwick nordw...@scam.xcf.berkeley.edu Date: 1999-09-08 17:38:56 -0700 To: freebsd-hackers@FreeBSD.ORG Subject: message queues for I/O (usenix paper) Content-id: 66138.93683747...@scam.xcf.berkeley.edu Delivered-to: freebsd-hackers@freebsd.org X-Loop: FreeBSD.ORG There is alot of talk going on over at the linux-kernel mailing list about implementing synchronous messaging for I/O. They are talking about a paper that was presented at USENIX: http://www.cs.rice.edu/~gaurav/papers/usenix99.ps The general idea is that select() and poll() fall over with large numbers of file descriptors for two reasons. First, scanning the interest list begins to consume more time. Second, the stateless nature between calls means that alot of redundant processing occurs. The solution these guys (the authors) say is to have a way of registering interest in descriptors, then you can call a procedure to find out what has changed since last time. I personally think that select() is just fine and can be implemented more efficiently than currently, but I would be willing to give it a shot at both cooperating with the Linux people to get a good Linux/FreeBSD API layed down and then implementing it. I know some of you heard this paper presented so does anybody have any ideas about it? Does anybody care? From the FWIW department, we have, in the Darwin source, an implementation of a select replacement that is designed to get around some of the (perceived or real) issues with select(), e.g., looking at a long (FD_SETSIZE or larger) array of bits several times in the kernel and in user space. In the available sources, this is represented in sys/ev.h, and is implemented only for sockets. Our tests indicate a roughly 5-10% speed improvement when a lot of sockets are in use but not exuberantly so. For Darwin in the future (the Core OS for Mac OS X), this scheme will be somewhat generalized, to provide a uniform mechanism for fielding events from any subsystem. It will be made more interesting by the need to incorporate mach message handling in addition to file-descriptor-based events. Have a look, should this be of interest. I'll be happy to field questions, since the doc is a bit, oh, scant... Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Need some advice regarding portable user IDs
From: Wilfredo Sanchez wsanc...@apple.com Date: 1999-08-18 14:28:54 -0700 To: Bill Studenmund wrstu...@nas.nasa.gov Subject: Re: Need some advice regarding portable user IDs Cc: Brian C. Grayson bgray...@marvin.ece.utexas.edu,freebsd-hackers@FreeBSD.ORG, tech-userle...@netbsd.org, p...@apple.com,warne...@apple.com, ume...@apple.com In-reply-to: 19990817213718.a28...@marvin.ece.utexas.edu X-Loop: FreeBSD.ORG Delivered-to: freebsd-hackers@freebsd.org X-Mailer: by Apple MailViewer (2.106) X-Mailer-Extensions: SWSignature 1.3.2 | Fred, right now what happens in MacOS when I take a disk which has sharing | credentials set up, and hook it into another machine? How are the | credentials handled there? I think Mac OS 8 will forget about the credentials. I don't actually know much about how sharing works. But the current file sharing behaviour is not entirely useful to think about, because it doesn't effect the local permissions (much), and the local permission are what I'm worried about. Exported filesystems are another story, and I don't want to compilcate things too much by worrying about that right now. My understanding of File Sharing [for Mac OS 8]is that (a) Mac OS doesn't understand identity, permissions, etc., so it can't talk about them; and (b) when you share a volume from a remote server, you login to that volume using a mechanism supported by the server. The client system isn't involved. Since you, at the keyboard, are really the only user of that system, the issue of what another logged-in user can do is moot. Note that although the enhanced HFS supports credentials (i.e, owner and group identity), Mac OS doesn't use this capability, and wouldn't know what to do with a volume that had this info filled in (i.e., can't make use of it). The whole issue of associating identity with permission is a bit perplexing. DCE attempted to solve this problem, and it got quickly out of hand. Regardless of whether you are using 32-bit integers, or 8-character login names, there's little or no guarantee that when you move a device containing this info from one site to another, the mapping from that identity to who you are will remain valid. In the meanwhile, there ought to be a simple version of this problem that we can solve :-}. I think I'll get down off this soap box for a bit... Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Berkeley IRS and NSS
From: Jason Thorpe thor...@nas.nasa.gov Date: 1999-08-03 12:04:48 -0700 To: Oscar Bonilla oboni...@fisicc-ufm.edu Subject: Re: Berkeley IRS and NSS Cc: freebsd-hackers@FreeBSD.ORG Delivered-to: freebsd-hackers@freebsd.org X-Loop: FreeBSD.ORG On Tue, 3 Aug 1999 11:28:29 -0600 Oscar Bonilla oboni...@fisicc-ufm.edu wrote: Anyone knows about the BSD Information Retrieval Service (IRS) mentioned in http://www.padl.com/nss_ldap.html ? It seems to accomplish the same thing as the NSS stuff we've been talking about. In NetBSD, we specifically didn't go with IRS because we felt it was not flexible enough. FWIW, it's also GPL'd, according to the web site. j -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Problem with fxp driver and 82559 cards
From: Jay Kuri j...@oneway.com Date: 1999-07-08 11:19:01 -0700 To: David Greenman d...@root.com Subject: Re: Problem with fxp driver and 82559 cards Cc: hack...@freebsd.org In-reply-to: 199907081808.laa29...@implode.root.com Delivered-to: freebsd-hackers@freebsd.org X-Loop: FreeBSD.ORG program... but if I go into the installer and try to transfer a distribution , it fails, locking in the same way. I'm talking with Intel to see if they have had similar problems. I read something in the source about the reciever has locked after garbage in the syncronization bits... could it be a similar problem with the new chip, perhaps exposed by certain types of equipment? What's the cable plugged into? We have tried: ATI switch (centrecom 3124tr) 10bT 3com SuperStack II (10/100) SMC TigerSwitch 10bT Same results on all of them. We've also tried setting media type to 10baseT/UTP in the 'ifconfig options' in sysinstall... no difference. Some off-the-wall thoughts. I haven't followed this closely, but noticed the last few messages. Apologies if this is in the wrong ballpark. Have you tried a hub or a switch configured to stick with half-duplex? Also, some switches go dark when there's a change in port status, as might happen if a driver reinitializes the link. The switches are executing a spanning tree algorithm on the new port, looking for loops. If the switches can be configured to not do this (only needed for switch-switch connection), you might try that as well. (I'm not sure if the install issue is occuring soon after a boot, or is something else). Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ARP breakage
From: Jasper O'Malley jo...@webnology.com Date: 1999-07-07 17:49:24 -0700 To: hack...@freebsd.org Subject: ARP breakage Delivered-to: freebsd-hackers@freebsd.org X-Loop: FreeBSD.ORG I haven't gotten much of a response in -stable, so I'll ask here. Any one know what happened to proxy ARP in recent incarnations of 3.2-STABLE? See problem report bin/12448, but in a nutshell: [snip] # arp -s 192.168.54.5 auto pub using interface ed1 for proxy with address 0:e0:29:32:21:ee arp: writing to routing socket: File exists ^^^ What broke? Out of curiosity, what does 'arp -a' show after the 'arp -s' command? Could be something like the alias response of 'ifconfig'... Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poll() vs select()
From: John Polstra j...@polstra.com Date: 1999-07-06 09:36:51 -0700 To: arc...@whistle.com Subject: Re: poll() vs select() Cc: hack...@freebsd.org In-reply-to: 199907050103.saa51...@bubba.whistle.com Delivered-to: freebsd-hackers@freebsd.org X-Loop: FreeBSD.ORG Organization: Polstra Co., Seattle, WA In article 199907050103.saa51...@bubba.whistle.com, Archie Cobbs arc...@whistle.com wrote: A new, faster event notification system would be great. But don't forget to include *all* events, not just file descriptor readability/writability. Yes! Yes! Yes! (I agree.) To add to the confusion, we've implemented something very similar for Mac OS X Server, designed to be a replacement for select(), and for use in a similar way to select's use in existing code. You can see it in the Darwin code. Check out sys/ev.h for a typically terse description of the API. In the released Darwin source, the code deals only with sockets. The Darwin release that deals with Mac OS X (possibly by fall) should have a more involved design that deals with a number of different kinds of events, including Mach messages (not a big deal for this group, of course). See www.publicsource.apple.com and follow the links to Darwin OS. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: System unique identifier.....
From: Matthew Jacob mja...@feral.com Date: 1999-06-24 15:03:56 -0700 To: freebsd-hackers@FreeBSD.ORG Subject: System unique identifier. Delivered-to: freebsd-hackers@freebsd.org X-Loop: FreeBSD.ORG I was talking about this on linux-kernel, but it also applies to *BSD... What're folks' motions of a settable system unique identifier, available prior to mountroot? This identifier has to be 64 bits or better and must be persistent across reboots. This could start a long discussion :-}. Some systems just take the IEEE MAC address from the motherboard, or that of the first interface it finds. Others use some algorithmic variation on that value, but it generally boils down to the same thing. For newer Intel boxes, you could just use the CPU chip... well, never mind. The main issue, I think, is that of persistence. How persistent do you want it? I'd bet that no matter what source you use, there's always the problem of it broke; I had to replace it; now what?. Kind of like your grandfather's axe, which has had six handles and two blades over its lifetime, but it's still your grandfather's axe. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: RE: DHCP, arp and de0
From: John Baldwin jobal...@vt.edu Date: 1999-06-15 16:23:24 -0700 To: Daniel J. O'Connor dar...@dons.net.au Subject: RE: DHCP, arp and de0 Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: xfmail.990613182527.dar...@dons.net.au X-Priority: 3 (Normal) Delivered-to: freebsd-hackers@freebsd.org X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Loop: FreeBSD.ORG On 13-Jun-99 Daniel J. O'Connor wrote: Hi, I have tried getting my system to use DHCP on my local network, but I'm having trouble. If I don't use DHCP everything works fine, but if I use DHCP I get the following messages appearing in my log file when I use ESD, and try and ping my LAN IP. Jun 13 17:35:21 guppy /kernel: arplookup 127.0.0.1 failed: could not allocate llinfo Jun 13 17:35:21 guppy /kernel: arpresolve: can't allocate llinfo for 127.0.0.1rt I'm not sure this is relevant, but the loopback address should *not* be fed to ARP. That's attached to the loopback interface (lo0), and shouldn't be seen on any wire. Could be your config is seriously fouled up. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Accessing special device files
From: Wes Peters w...@softweyr.com Date: 1999-06-01 11:50:23 -0700 To: Julian Elischer jul...@whistle.com Subject: Re: Accessing special device files Cc: Zhihui Zhang zzh...@cs.binghamton.edu, freebsd-hackers@FreeBSD.ORG X-Accept-Language: en Delivered-to: freebsd-hackers@freebsd.org X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Loop: FreeBSD.ORG Organization: Softweyr LLC Julian Elischer wrote: Bzzzt! On Tue, 1 Jun 1999, Wes Peters wrote: Zhihui Zhang wrote: I write a small program to read/write each FreeBSD partition via special device file names, e.g. /dev/wd0s2e, /dev/rwd0s2e, etc. I have two questions about doing this: I know this is confusing but you are 100% backwards.. . ??? dd verifies the behavior you report: The rwd device is clearly a character-special device, the wd device a block special. Character devices can always be read byte-at-a-time, by definition. When did the semantics of this change? Don't let the name fool you. The term 'character device' doesn't mean byte-at-a-time. It's just a name in opposition to block device, which is buffered. The real distinction is buffered (block) v. un-buffered (character), and even that's a bit blurry. Raw (character) disk devices have always had this behavior. Back in The Good Old Days, physio() actually worked direct to user buffers, so the rule was block size and granularity, was dictated by a combo of what physio() and the device driver were willing to do. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mbuf stuff
From: Dennis den...@etinc.com Date: 1999-05-27 09:43:09 -0700 To: hack...@freebsd.org Subject: mbuf stuff We've encountered a situation where mbuf allocations inside a device interrupt handler fails occasionally...and it always seems to happen when rtalloc() is interrupted. Is this due to some sort of locking (rtalloc is run at splnet())...should it perhaps be run at splimp() to avoid this problem? What other causes for mbuf failures might reasonably be expected? Is allocating mbufs at interrupt time something that wasnt expected in the original system design? This may be already clear, but just in case: m_get has an argument (nowait) to tell the allocater whether it's ok to sleep to wait for buffers in a low-memory situation. When called from interrupt level, the call can't sleep, so you have to set 'nowait' to M_DONTWAIT. This means that you *have* to deal with a null return in this case. In your specific case, rtalloc() calls rtalloc1(), which raises the processor priority to splnet (I'm looking at a 3.1 source base). You can interrupt rtalloc() without harm. I do wonder why you're always in that routine when this occurs, but I can't provide any illumination there. How frequently does this occur? Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
From: adr...@freebsd.org Date: 1999-05-16 04:59:51 -0700 To: Bernd Walter ti...@cicely.de Subject: Re: ifconfig: changing mac address Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of Sun, 16 May 1999 11:48:42 +0200.19990516114842.a48...@cicely8.cicely.de Delivered-to: freebsd-hackers@freebsd.org X-Loop: FreeBSD.ORG overloaded for this, no? The driver could fail the request if it didn't support it; or if it has run out of slots for aliases. There should also be (I think) a way to tell the driver to go to promiscuous mode to emulate this (an I really want this request?), but I'm not sure it should be the default response to the set hardware address request. An alias would be nice. A standby system must be reachable before it will be active and will need another MAC to be. But I don't see any sence in having more than one MAC on one IP-Address. So talking on IP it should be an optional argument to the ip-alias. Remembering that if you add multiple hw addresses to a single card, you then have to lock down IP addresses to hw addresses or things become very very very confused. Can someone with a little more experience in the IP/arp code explain this one a bit better? I'm just waving my hands here, but first, I think drivers should be able to provide this service without getting too hung up in the implications (i.e., they just pass incoming data up the line and let another piece of the system deal with it; and for output, they take fully-formed packets and get the bits on the wire [I did say I was hand-waving]). I think the upper layers might be able to keep this stuff straight, e.g., by providing virtual interfaces above the physical, to discriminate on physical addresses. Also, this isn't IP-specific, since the Mac makes use of this capability for support of other OSs and their [unprintable] stacks (this in response to the concern that about more than one MAC address per IP address). Being able to use this functionality may take a bit more engineering, but it seems that there is good reason to consider it as part of the driver interface. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
From: Greg Lehey g...@lemis.com Date: 1999-05-14 19:21:11 -0700 To: Dan Nelson dnel...@emsphone.com Subject: Re: ifconfig: changing mac address Cc: David Scheidt dsche...@enteract.com,Mark J. Taylor mtay...@cybernet.com, Daniel Eischen eisc...@vigrid.com,freebsd-hackers@FreeBSD.ORG In-reply-to: 19990514211533.a27...@dan.emsphone.com; from Dan Nelson on Fri,May 14, 1999 at 09:15:33PM -0500 Phone: +61-8-8388-8286 Mobile: +61-41-739-7062 X-Mailer: Mutt 0.95.4i X-Loop: FreeBSD.ORG X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia WWW-Home-Page: http://www.lemis.com/~grog Fax: +61-8-8388-8725 Delivered-to: freebsd-hackers@freebsd.org On Friday, 14 May 1999 at 21:15:33 -0500, Dan Nelson wrote: In the last episode (May 14), David Scheidt said: On Sat, 15 May 1999, Greg Lehey wrote: :It seems there's a need, and the possibility. Would somebody like :to suggest a syntax? ifconfig interface ether ab:cd:ef:fe:dc:ab [options] makes sense to me. And the next step would be to make the kernel realize that two cards ifconfig'd with the same MAC address are meant to be bonded together as one route (lots of switches support this). I have some machines that I'd love to be able to get 20MB/sec bandwidth between transparently. I think you need to reconsider that idea. How are you going to double the bandwidth of the wire? I think Dan's thinking of switched ethernet, with a high-speed switch that can handle the bandwidth. Clearly won't work on thinnet, but with 10BaseT, you (can) have a switch providing increased bandwidth. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
From: Mike Smith m...@smith.net.au Date: 1999-05-15 09:40:39 -0700 To: Greg Lehey g...@lemis.com Subject: Re: ifconfig: changing mac address Cc: Mark J. Taylor mtay...@cybernet.com,Daniel Eischen eisc...@vigrid.com, freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of Sat, 15 May 1999 11:13:49 +0930.19990515111348.k89...@freebie.lemis.com Delivered-to: freebsd-hackers@freebsd.org X-Mailer: exmh version 2.0.2 2/24/98 X-Loop: FreeBSD.ORG It seems there's a need, and the possibility. Would somebody like to suggest a syntax? The precedent would be the socket ioctls SIOCGIFHWADDR and SIOCSIFHWADDR. The Linux emulator suppors the get-only version already. It's already been mentioned that some adapters support multiple unicast media addresses (the DEC parts; the on-board enets for (most) PowerPC Macs; ...). It would be good to support aliases for media addresses as well. The 'alias' keyword for ifconfig could be overloaded for this, no? The driver could fail the request if it didn't support it; or if it has run out of slots for aliases. There should also be (I think) a way to tell the driver to go to promiscuous mode to emulate this (an I really want this request?), but I'm not sure it should be the default response to the set hardware address request. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
[Apologies if this is duplicated, sort of; I inadvertently lost power as I was sending a reply to this, and I don't have a record that it was sent]. From: Nate Williams n...@mt.sri.com Date: 1999-05-14 10:11:52 -0700 To: steve.gai...@db.com Subject: Re: ifconfig: changing mac address Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: 199905141618.raa03...@pow.srv.uk.deuba.com Delivered-to: freebsd-hackers@freebsd.org X-Mailer: VM 6.34 under 19.16 Lille XEmacs Lucid X-Loop: FreeBSD.ORG Is it possible to change the mac address of an ethernet card using ifconfig? Not in any 'standard' card, no. Some cards (in SUN workstations) allow you to swap the EEPROM with the mac address, and I'll bet somewhere someone has designed a card with a programmable mac address, but normally it's not settable. I don't believe this is correct. The cards I'm familiar with only accept unicast packets when programmed with a specific MAC address. This is normally the one that's in a ROM associated with the device somehow, but there's no reason it can't be changed. DECNet, for example, assumes for some protocols at least, that the MAC address is one from the block of addresses owned by DEC. CompaqNet? Sheesh. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
