Re: rpc.lockd and true NFS locks?
Don Coleman wrote: David, I wrote the NFS lockd code for BSD/OS (it's based on some user land stuff Keith Bostic did, and then Kirk McKusick helped clean up my basic design and the VFS layering for the server/kernel side). We have an application that is desperately in need of client side NFS locks, so I'm highly motivated to test this out if it can be ported to either -stable or -current. Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
On Sat, Dec 16, 2000 at 06:37:56PM -0800, Jordan Hubbard wrote: PS. Before this starts a flame war, let me say that I really believe that MacOS X is a very good thing for everyone involved, although the choice of Mach for the microkernel seems a little arbitrary if not misguided. It's hardly arbitrary, though the jury's still out as to whether it's misguided or not. You may remember that Apple bought a little company called NeXT a few years back. Well, that company's people had a lot to do with the OS design of OS X and let's not forget the design of NeXTStep. Yeah, but in what sense is that use of Mach a serious microkernel, if it's only got one server: BSD? I've never understood the point of that sort of use. It makes sense for a QNX or GNU/Hurd or minix or Amoeba style of architecture, but how does Mach help Apple, instead of using the bottom half of BSD as well as the top half? Not that there can't be a good reason. There probably is. I just haven't heard it. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
Yeah, but in what sense is that use of Mach a serious microkernel, if it's only got one server: BSD? I've never understood the point of that sort of use. It makes sense for a QNX or GNU/Hurd or minix or Amoeba style of architecture, but how does Mach help Apple, instead of using the bottom half of BSD as well as the top half? That's actually a much better question and one I can't really answer. One theory might be that the NeXT people were simply Microkernel bigots for no particularly well-justified reason and that is simply that. Another theory might be that they were able to deal with the machine-dependent parts of Mach far more easily given its comparatively minimalist design and given their pre-existing expertise with it. Another theory, sort of related to the previous one, is that Apple has some sort of plans for the future which they're not currently sharing where Mach plays some unique role. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
On Sat, Dec 16, 2000 at 04:27:20PM -0600, Dan Nelson wrote: In the last episode (Dec 16), Axel Thimm said: Wouldn't that mean, that you might cause data corruption if, say, I was to read my mail from a FreeBSD box over an NFS mounted spool directory (running under OSF1 in our case), and I decided to write back the mbox to the spool dir the same moment new mail is delivered? That's why dotlocking is recommended for locking mail spools. Both procmail and mutt will dotlock your mail file while it's being accessed. This was just a test case above. Not all programs are kind enough to allow control of their locking strategy. What about samba accessing NFS volumes in a transparent net or pure sendmail w/o procmail? Especially if your mail server is already at heavy load serving O(1000) users, forcing each incomming mail to be passed to procmail would must certainly increase the load too much. (Maybe sendmail and samba can also be compiled with dotlocking methods, these are also just examples). Also not all our users want to switch to mutt, we have to support a wide range of mail readers. Axel. -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Writing Device Drivers
Hello, I am very keen to develop for FreeBSD, and would like to start writing device drivers for various hardware that is unsupported. I have some knowledge of C, and have had a good read of "The design and Implementation of..." and bits and pieces of the kernel and driver sources. Does anyone have any good tips to get started / HowTo's, or some simple examples that will give me knowledge like the PC Speaker or something simple like that? Thanks, Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: ESS Sound Driver
Hi, I got hold of you driver, compiled and installed it. After booting, I logged in as root and typed: # kldload snd_maestro3 but this returned the following error message: pcm0: ESS Technology Maestro3 at device 12.0 on pci0 pcm0: Unable to map i/o space device_probe_and_attach: pcm0 attach returned 6 Any ideas on what I am doing wrong?? Any help appreciated Jamie On 2000.12.15 16:47:16 + "Long, Scott" wrote: Myself and Darrell Anderson are working on a driver. Check out http://people.freebsd.org/~scottl/maestro3 for mine or http://www.cs.duke.edu/~anderson/freebsd/maestro3xxx for his. The PCI id mentioned by the original poster (0x199a125d) is supported by this driver, though I haven't tested it. -Original Message- From: Michel Talon [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 9:42 AM To: [EMAIL PROTECTED] Subject: Re: ESS Sound Driver On Fri, Dec 15, 2000 at 04:10:09PM +, Jamie Heckford wrote: Hi, Could anyone offer any guidance on getting the following sound card to work? It is in a Samsung GT8700 laptop - and I am using FreeBSD 4.2-RELEASE. Windows identifies the card as an ESS Maestro PCI Audio (WDM) - IRQ 5 I have seen recently a HP laptop with a maestro 3 audio card. I have been able to run the sound card only with the Alsa drivers under Linux. Apparently the FreeBSD drivers are able to run only the maestro 2 and 2E. -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
On Sun, Dec 17, 2000 at 12:14:07AM +, Tony Finch wrote: Patryk Zadarnowski [EMAIL PROTECTED] wrote: Now that I think of it, there aren't many commercial microkernel systems out there with the possible exception of QNX and lots of little embedded toys. Mac OS X is based on Mach. Yes, but Mac OS X isn't Mach and it isn't a microkernel [*] -- it's a hybrid. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] [*] For most, but perhaps not all, values of microkernel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
PS. Before this starts a flame war, let me say that I really believe that MacOS X is a very good thing for everyone involved, although the choice of Mach for the microkernel seems a little arbitrary if not misguided. It's hardly arbitrary, though the jury's still out as to whether it's misguided or not. You may remember that Apple bought a little company called NeXT a few years back. Well, that company's people had a lot to do with the OS design of OS X and let's not forget the design of NeXTStep. Yeah, but in what sense is that use of Mach a serious microkernel, if it's only got one server: BSD? I've never understood the point of that sort of use. It makes sense for a QNX or GNU/Hurd or minix or Amoeba style of architecture, but how does Mach help Apple, instead of using the bottom half of BSD as well as the top half? Kernel threads out of the box? Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
Jordan Hubbard wrote: Yeah, but in what sense is that use of Mach a serious microkernel, if it's only got one server: BSD? I've never understood the point of that sort of use. It makes sense for a QNX or GNU/Hurd or minix or Amoeba style of architecture, but how does Mach help Apple, instead of using the bottom half of BSD as well as the top half? That's actually a much better question and one I can't really answer. One theory might be that the NeXT people were simply Microkernel bigots for no particularly well-justified reason and that is simply that. Another theory might be that they were able to deal with the machine-dependent parts of Mach far more easily given its comparatively minimalist design and given their pre-existing expertise with it. Another theory, sort of related to the previous one, is that Apple has some sort of plans for the future which they're not currently sharing where Mach plays some unique role. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message I tried QNX! If microkernel is low performance, why QNX is so fast? It makes no sense to me! Is there any choice on QNX beats a freebsd server in , say, http server ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
On Sun, 17 Dec 2000, Nate Williams wrote: Kernel threads out of the box? The Mach kernel makes use of a thread primitive and a task primitive; however, their BSD OS personality is largely single-threaded with something approximately equivilent to our Giant -- they refer to this as a "Funnel", through which access to the BSD code is funneled so as to prevent problems. My understanding from a brief chat while in their Cupertino office is that they are in the process of gradually pushing locks down for specific subsystems (networking, etc), in much the same style we are. While there, I suggested that closer coordination between our development teams could save a lot of redundant work, given that the primitives we're using are probably quite similar (although presumably non-identical). It would be great if someone wanted to step up and help Apple coordinate their work with our work better, as it would allow more code sharing and more rapid development, as well as more wide-spread testing. If anyone is interested in looking at doing this, I have a list of relevent contacts in their kernel group. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
Kernel threads out of the box? The Mach kernel makes use of a thread primitive and a task primitive; however, their BSD OS personality is largely single-threaded with something approximately equivilent to our Giant -- they refer to this as a "Funnel", through which access to the BSD code is funneled so as to prevent problems. Interesting. My understanding from a brief chat while in their Cupertino office is that they are in the process of gradually pushing locks down for specific subsystems (networking, etc), in much the same style we are. While there, I suggested that closer coordination between our development teams could save a lot of redundant work, given that the primitives we're using are probably quite similar (although presumably non-identical). It would be great if someone wanted to step up and help Apple coordinate their work with our work better, as it would allow more code sharing and more rapid development, as well as more wide-spread testing. If anyone is interested in looking at doing this, I have a list of relevent contacts in their kernel group. The reason I mentioned the above is that Apple has HotSpot (Sun's fast Java VM) running under OS/X, which requires kernel threads. Until FreeBSD's kernel threads are a bit more 'user-friendly', we can't do anything with HotSpot. (As I understand it, HotSpot runs very well on the OS/X, so they seems to have gotten that part right...) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
On Sat, 16 Dec 2000, Jordan Hubbard wrote: PS. Before this starts a flame war, let me say that I really believe that MacOS X is a very good thing for everyone involved, although the choice of Mach for the microkernel seems a little arbitrary if not misguided. It's hardly arbitrary, though the jury's still out as to whether it's misguided or not. You may remember that Apple bought a little company called NeXT a few years back. Well, that company's people had a lot to do with the OS design of OS X and let's not forget the design of NeXTStep. The Darwin kernel is a microkernel in only a few senses of the word. It does have a small central code component that provides primitives for context and address space management, message passing, and so on. It does allow you to layer a variety of "personalities" on top of it providing the full functionlity of traditional operating systems with greater modularity and nice distributed system properties. However, it's also a monolithic kernel in the sense that it runs in a single address space, and the BSD personality included fits quite well in the "monolithic" definition, given that it's a large chunk of the FreeBSD kernel. Personally, I think their design has some nice properties, and that it was the right choice for them at the time. They had a large existing, well-designed and architected kernel environment based on a combination of Mach and BSD (NeXTStep), which already had all the right primitives and implementation for a highly scalable, multi-threaded, multi-processor kernel environment. When they branched the FreeBSD code, it was barely multi-processor, let alone multi-threaded. They took the best of the FreeBSD world (mature userland, mature network stack, well-defined ABI and API, POSIX-like libraries, liberal license), and replaced much of the old NeXTStep (BSD 4.3?) equivilents. Given that FreeBSD is now moving in the direction of greater architectural maturity in terms of kernel synchronization primitives allowing fine-grained kernel threading, strong SMP support, multi-platform support, I would expect that a sensible course would be to try and resolve some of the code-base difference between the two platforms, allowing Apple to continue to track our developments while retaining their proprietary userland environment. In particular, it would be nice to re-converge on locking/VFS/threading/SMP issues where possible. I actually like their HFS+ file system a lot (although I'd throw out the hard link hack, and hard links themselves) as it offers high performance directory operations. I'd fix their weird VOP's that try to take advantage of that, and work with them to fix the VFS problems that must hound them as much as us. I'd also work with them to integrate back some of their NFS fixes. I think that the determining factor for the success or failure of OS X is not its kernel architecture -- it's whether or not their userland interface diverges sufficiently from the OS 9 interface that their user base doesn't follow them to the new platform. The interface is what will make or break OS X; thus far they've managed to hide most of the nastiness of UNIX by adopting the NeXTStep netinfo configuration and directory service environment -- I've been seriously considering looking at adapting FreeBSD to use netinfo also, given that it provides a time-tested model for configuration management (local and distributed). It probably needs some cleaning up in the security sense, and possibly rewriting, but it's a strong starting point, and liberally licensed. What runs under that doesn't matter as long as Apple can support it and provide extensibility required by hardware vendors (their IOKit provides a fixed and object-oriented API for providing device support and management, and we should be comparing newbus to it and seeing what we missed :-). I'm impressed by their work and by their vendor support -- it comes shipped with Internet Explorer as the default native browser, and has strong commitments for native versions from software vendors such as Adobe and Microsoft -- the first UNIX system I've seen that does that while remaining a desktop pricetag. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
On Sun, 17 Dec 2000, Andrew Reilly wrote: Yeah, but in what sense is that use of Mach a serious microkernel, if it's only got one server: BSD? I've never understood the point of that sort of use. It makes sense for a QNX or GNU/Hurd or minix or Amoeba style of architecture, but how does Mach help Apple, instead of using the bottom half of BSD as well as the top half? What I'd really like to know, and haven't had a chance to investigate much, is to what extent the Mach primitives are used by their userland environment. I.e., does their software really just use the BSD ABI/API, or does it rely on the Mach IPC primitives for performance in their graphics subsystem. If it relies only on the BSD interface, that gives them a path towards migrating more in the direction of a pure FreeBSD kernel, if they desire, or swapping it out with whatever they choose, as well as leveraging a lot of other work (in particular, security work) based on UNIX-like ABI/API's. If they do rely on the Mach primitives, then that may be less easy. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
On Sun, Dec 17, 2000 at 12:27:55PM -0500, Robert Watson wrote: -- I've been seriously considering looking at adapting FreeBSD to use netinfo also, given that it provides a time-tested model for configuration management (local and distributed). It probably needs some cleaning up in the security sense, and possibly rewriting, but it's a strong starting point, and liberally licensed. Most of netinfo will be supported via nsswitch and PADL.COM's nss-netinfo for FreeBSD 5.0. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
On Sun, 17 Dec 2000, Jacques A. Vidrine wrote: On Sun, Dec 17, 2000 at 12:27:55PM -0500, Robert Watson wrote: -- I've been seriously considering looking at adapting FreeBSD to use netinfo also, given that it provides a time-tested model for configuration management (local and distributed). It probably needs some cleaning up in the security sense, and possibly rewriting, but it's a strong starting point, and liberally licensed. Most of netinfo will be supported via nsswitch and PADL.COM's nss-netinfo for FreeBSD 5.0. That's great news -- I assume however that this is limited to the account directory service functionality, as opposed to the more general configuration parameters (login.conf equivs, etc)? Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Writing Device Drivers
At 13:02 17/12/00 +, you wrote: Does anyone have any good tips to get started / HowTo's, or some simple examples that will give me knowledge like the PC Speaker or something simple like that? This is turning into a FAQ, but don't worry about it. The usual answer is to take one of the existing drivers and work out what it does. There's also a script for making shell drivers under /usr/share/examples/drivers. As for things like "how does DMA work?", "what exactly is an interrupt and what do I do with it?" or "what's the story with memory ranges and devices then?" then I'm afraid I can't help you there. In fact (to -hackers) this strikes me as one of the more fundamental problems of free software: I would go and write/fix some device drivers (for example the unknown phy in fxp that bothers me so much), except I can't really get a handle on how you're supposed to start on these things. Comments? URL's for IRQ101? Perhaps I should just stop whingeing and go hack with it to see what happens? (probably best). Jamie Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
On Sun, Dec 17, 2000 at 02:02:56PM -0500, Robert Watson wrote: That's great news -- I assume however that this is limited to the account directory service functionality, as opposed to the more general configuration parameters (login.conf equivs, etc)? That's correct, at least for the near term. However, over time I expect more C library functions will be supported (by being rewritten to use nsdispatch(3)). -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
service environment -- I've been seriously considering looking at adapting FreeBSD to use netinfo also, given that it provides a time-tested model for configuration management (local and distributed). It probably needs some cleaning up in the security sense, and possibly rewriting, but it's a strong starting point, and liberally licensed. What runs under that I think that's a good idea. I've been having some of the same thoughts. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
[This typo came from NetBSD, so in this particular source I have no intention of changing the style.] What do folks think about 1)if (data) free(data); versus 2)free(data); versus 3)#define xfree(x) if ((x) != NULL) free(x); xfree(data); -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] On Sun, Dec 17, 2000 at 01:10:41PM -0800, Jacques Vidrine wrote: nectar 2000/12/17 13:10:41 PST Modified files: lib/libc/gen getgrent.c Log: Fix mostly harmless typo: if (data); free(data); Discovered by: emacs cc-mode Revision ChangesPath 1.19 +2 -2 src/lib/libc/gen/getgrent.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit:src/lib/libc/gen getgrent.c)
On Sunday, December 17, 2000, Jacques A. Vidrine wrote: What do folks think about 1)if (data) free(data); versus 2)free(data); versus 3)#define xfree(x) if ((x) != NULL) free(x); xfree(data); 2. The C standard dictates that free() does nothing when it gets a NULL argument. The other two are just extra clutter. -- +---+-+ | Chris Costello| This system will self-destruct in five minutes. | | [EMAIL PROTECTED] | | +---+-+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
On Sun, 17 Dec 2000, Chris Costello wrote: On Sunday, December 17, 2000, Jacques A. Vidrine wrote: What do folks think about 1)if (data) free(data); versus 2)free(data); versus 3)#define xfree(x) if ((x) != NULL) free(x); xfree(data); 2. The C standard dictates that free() does nothing when it gets a NULL argument. The other two are just extra clutter. Agreed. However, in the kernel, all free()s should be made as in (1), in my opinion. (2) is dangerous, and (3) would just obfuscate the code. (I know this does not apply to the commit, but should be noted) -- +---+-+ | Chris Costello| This system will self-destruct in five minutes. | | [EMAIL PROTECTED] | | +---+-+ Later, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit:src/lib/libc/gen getgrent.c)
On Sunday, December 17, 2000, Bosko Milekic wrote: Agreed. However, in the kernel, all free()s should be made as in (1), in my opinion. (2) is dangerous, and (3) would just obfuscate the code. (I know this does not apply to the commit, but should be noted) Yes, I agree; however free() in the kernel is an entirely different case and is not governed by the C standard. If you ask anyone in comp.lang.c, they'll tell you that our kernel is only written in a language _similar_ to C, and I can understand that, because many standard C functions behave differently in the kernel. (malloc and free come to mind, obviously.) -- +---++ | Chris Costello| Don't stop at one bug. | | [EMAIL PROTECTED] || +---++ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
On Sun, Dec 17, 2000 at 03:17:35PM -0600, Chris Costello wrote:
2. The C standard dictates that free() does nothing when it
gets a NULL argument.
Well, it dictates that free(NULL) is safe -- it doesn't dictate that
it ``does nothing''. Which brings me to my next comment:
The other two are just extra clutter.
I suspect that the programmer writing
if (data)
free(data);
is motivated by the wish to avoid the function call overhead if you
already know darn well that there is nothing to free. In the
multithreaded case, there is probably some locking going on, too.
I don't blame authors of storage allocation code if they do not write
free like this:
void
free(void *p)
{
if (p == NULL)
return;
.
.
.
It would be silly to optimize for freeing NULL pointers.
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit:src/lib/libc/gen getgrent.c)
On Sunday, December 17, 2000, Jacques A. Vidrine wrote:
I don't blame authors of storage allocation code if they do not write
free like this:
void
free(void *p)
{
if (p == NULL)
return;
.
.
.
It would be silly to optimize for freeing NULL pointers.
You mean as seen in:
static void
ifree(void *ptr)
{
struct pginfo *info;
int index;
/* This is legal */
if (!ptr)
return;
.
.
.
called by free():
void
free(void *ptr)
{
THREAD_LOCK();
malloc_func = " in free():";
if (malloc_active++) {
wrtwarning("recursive call.\n");
malloc_active--;
return;
} else {
ifree(ptr);
.
.
.
That's how it's worked since before FreeBSD came into being.
It wasn't implemented the same, but it behaved the same.
--
+---++
| Chris Costello| All the simple programs have been |
| [EMAIL PROTECTED] | written, and all the good names taken. |
+---++
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
On Sun, Dec 17, 2000 at 03:36:56PM -0600, Chris Costello wrote:
On Sunday, December 17, 2000, Jacques A. Vidrine wrote:
It would be silly to optimize for freeing NULL pointers.
You mean as seen in:
[snip ifree(), which checks for a NULL pointer, first thing]
called by free():
void
free(void *ptr)
{
THREAD_LOCK();
malloc_func = " in free():";
if (malloc_active++) {
wrtwarning("recursive call.\n");
malloc_active--;
return;
} else {
ifree(ptr);
.
.
.
That's how it's worked since before FreeBSD came into being.
It wasn't implemented the same, but it behaved the same.
I may have missed your point ... or maybe you are just agreeing with
what I wrote. For this particular implementation of free, you get the
following for `free(foo)' when foo == NULL:
function call and stack overhead for free()
lock something if we are threaded
pointer assignment
increment
compare and branch
function call and stack overhead for ifree()
compare and branch
unwind ifree()
More stuff if HAVE_UTRACE
decrement
unlock something
unwind free()
Compare to `if (foo) free(foo);'
compare and branch
i.e. FreeBSD's free() is not optimized for freeing NULL pointers. Not
that I think it should be -- as I said, that would be silly.
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit:src/lib/libc/gen getgrent.c)
On Sunday, December 17, 2000, Jacques A. Vidrine wrote: I may have missed your point ... or maybe you are just agreeing with what I wrote. For this particular implementation of free, you get the following for `free(foo)' when foo == NULL: function call and stack overhead for free() lock something if we are threaded pointer assignment increment compare and branch function call and stack overhead for ifree() compare and branch unwind ifree() More stuff if HAVE_UTRACE decrement unlock something unwind free() FreeBSD's free() is not optimized for freeing NULL pointers. Not that I think it should be -- as I said, that would be silly. The code I pasted _was_ FreeBSD's code, and it does optimize for freeing NULL pointers. You can still check for the pointer if you wish, before you call free(). -- +---+-+ | Chris Costello| Backups? We doan *NEED* no | | [EMAIL PROTECTED] | steenking baX%^~,VbKxNO CARRIER | +---+-+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
On Sun, Dec 17, 2000 at 04:04:42PM -0600, Chris Costello wrote: On Sunday, December 17, 2000, Jacques A. Vidrine wrote: I may have missed your point ... or maybe you are just agreeing with what I wrote. For this particular implementation of free, you get the following for `free(foo)' when foo == NULL: function call and stack overhead for free() lock something if we are threaded pointer assignment increment compare and branch function call and stack overhead for ifree() compare and branch unwind ifree() More stuff if HAVE_UTRACE decrement unlock something unwind free() FreeBSD's free() is not optimized for freeing NULL pointers. Not that I think it should be -- as I said, that would be silly. The code I pasted _was_ FreeBSD's code, Yes, I know. and it does optimize for freeing NULL pointers. How so? Many instructions that are unnecessary are executed when you call free with a NULL pointer (read what I wrote above). To optimize for this case would be to check whether or not the pointer was NULL before doing anything else. This is kinda silly, who the hell started this thread? :-) You can still check for the pointer if you wish, before you call free(). Of course. And it seems a prudent thing to do if NULL pointers are not uncommon in the code path. I hate to give up a line for if (data) free(data); but neither do I care for ``if (data) free(data);''. I guess if I were writing several statements like that in a single file, I would consider the macro route (e.g. xfree). -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Writing Device Drivers
David Preece wrote: At 13:02 17/12/00 +, you wrote: Does anyone have any good tips to get started / HowTo's, or some simple examples that will give me knowledge like the PC Speaker or something simple like that? This is turning into a FAQ, but don't worry about it. The usual answer is to take one of the existing drivers and work out what it does. There's also Look at the DaemonNews (www.daemonnews.org), the Blueprints column. If I remember the months correctly, in the July 2000 issues there is an introduction into FreeBSD device drivers by Alexander Langner, and in June and August issues there are my articles on CAM (SCSI) drivers and ISA device drivers respectively. There also were articles on the Netgraph networking subsystem and on writing drivers as modules. I believe that these articles have been turned into sections of the Handbook as well but I'm not sure where exectly in Handbook they are. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Writing Device Drivers
David Preece wrote: At 13:02 17/12/00 +, you wrote: Does anyone have any good tips to get started / HowTo's, or some simple examples that will give me knowledge like the PC Speaker or something simple like that? This is turning into a FAQ, but don't worry about it. The usual answer is to take one of the existing drivers and work out what it does. There's also a script for making shell drivers under /usr/share/examples/drivers. As for things like "how does DMA work?", "what exactly is an interrupt and what do I do with it?" or "what's the story with memory ranges and devices then?" then I'm afraid I can't help you there. In fact (to -hackers) this strikes me as one of the more fundamental problems of free software: I would go and write/fix some device drivers (for example the unknown phy in fxp that bothers me so much), except I can't really get a handle on how you're supposed to start on these things. Comments? URL's for IRQ101? Perhaps I should just stop whingeing and go hack with it to see what happens? (probably best). Jamie Dave I've had to deal with this frustration too (and I still do) because there is no good documentation to speak of for writing FreeBSD device drivers. It wouldn't be so bad if there were man pages for many of the commonly used functions like rman_get_bustag(), etc. This way you could study the code of other drivers and quickly be able to identify and understand the function calls you were seeing. Instead of grumbling "what the !@#$ does that function call do?" just type "man 9 foo" or whatever. This is IMHO one of the advantages linux has over FreeBSD. You can run by your local Barnes Noble bookstore and pick up a copy of "Linux Device Drivers" and start writing code that you actually understand. GRIPE You'd think a couple of these FreeBSD wizards would get together and write "FreeBSD Device Drivers" to spare us the pain and make a little $$ while they're at it! /GRIPE Just my 2 cents. -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
DOS Emulation KLD
I've had this idea kicking around for some time, so I decided I would throw it out there and see if anyone was interested or had any ideas. I'm wondering why we can'twrite basic DOS emulation as a KLD. DOS programs are x86 code, a majority of it usually doing basic mundane (userland acceptable) things. The only problems would come about when interrupts were called and system memory locations were written to. It is my understanding that under x86-32 virtual machines, such instructions are "illegal" and therefore caught by the OS's virtual machine driver, and emulated. I think for basic int 21h services, and BIOS keyboard and text functions, this wouldn't be that difficult to do, and would allow simple text based DOS programs to run under FreeBSD. The DOS programs would see the file system in an 8.3 format, case insensitive, and would be able to use and save files without any real major modification. The same way VFAT handles long file names, DOS could handle FFS file names (eg: alongfilename.txt becomes alongf~1.txt). With the file system emulated, the basic interrupts caught and emulated, and everything else stubbed, many simple dos programs would function under FreeBSD. For example, although of course we have midnight commander, there is no real reason why the original Norton Commander could not run under FreeBSD. I'm not suggesting NC would be better than MC, but what I am suggesting is that a simple program like NC, which writes to the screen and manages files, should have no problem running in the BSD environment. I know there are emulation programs available in ports, but I was thinking along the lines of a KLD, which is automatically loaded when a DOS exe file is executed from the prompt. I'm going to look into this, and maybe with some help, draft a simple implementation to see if it's feasible. Any comments or suggestions welcome.
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
"Jacques A. Vidrine" [EMAIL PROTECTED] writes: What do folks think about 1)if (data) free(data); versus 2)free(data); versus 3)#define xfree(x) if ((x) != NULL) free(x); xfree(data); (2), unless you can show that you actually win something by the optimization in (1), and if you repeat it enough I would vote for doing an inline function similar to the one in (3). This is of course for user-level free since kernel free has different parameters. /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Writing Device Drivers
Devin Butterfield [EMAIL PROTECTED] writes: This is IMHO one of the advantages linux has over FreeBSD. You can run by your local Barnes Noble bookstore and pick up a copy of "Linux Device Drivers" and start writing code that you actually understand. It's less of an advantage than you might think. Kernel internals are moving targets, especially in the Linux world, and it doesn't take very much time for a book to become outdated. For example, when I started writing drivers for Linux 2.2, all I could find was books that covered 2.0 and early versions of 2.1. Nothing documented the current kernel, and because of the drastic changes between versions, much of the documentation for 2.0 was misleading. --nat -- nat lanza - research programmer, parallel data lab, cmu scs [EMAIL PROTECTED] http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes: : What do folks think about : : 1)if (data) : free(data); : : versus : : 2)free(data); : : versus : : 3)#define xfree(x) if ((x) != NULL) free(x); : xfree(data); Number 2. ANSI-C (aka c89) requires that free(NULL) work. We shouldn't go out of our way to pander to those machines where it doesn't. Number 1 is my second choice assuming for some reason number 2 isn't an option. Number 3 is the same as #2, imho, except that it gratuioutsly uglifies the code by the introduction of a non-standard API and an additional macro. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes: : I hate to give up a line for : : if (data) : free(data); : : but neither do I care for ``if (data) free(data);''. I guess if I : were writing several statements like that in a single file, I would : consider the macro route (e.g. xfree). No offense, but this strikes me as a premature, sub-micro optimization. I doubt that you could measure any difference between if (foo) free(foo); and free(foo); in the real world. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Writing Device Drivers
Devin Butterfield wrote: This is IMHO one of the advantages linux has over FreeBSD. You can run by your local Barnes Noble bookstore and pick up a copy of "Linux Device Drivers" and start writing code that you actually understand. And they'll run fine in Linux 2.0.43pre11 or something like that. All of those books are out of date by the time they hit the shelf in your bookstore, and given the slew rate of Linux kernel APIs, finding any of them useful seems pretty doubtful. Well-written man pages for FreeBSD would certainly be a boon, but printed books wouldn't really help that much. There are books available on writing BSD device drivers, but the kernel APIs have moved on since then, as you've noticed. Perhaps a good project for someone who wants to under- stand FreeBSD device drivers would be to update the section 9 man pages? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
Bill Fumerola wrote: On Sat, Dec 16, 2000 at 06:37:56PM -0800, Jordan Hubbard wrote: It's hardly arbitrary, though the jury's still out as to whether it's misguided or not. You may remember that Apple bought a little company called NeXT a few years back. Well, that company's people had a lot to do with the OS design of OS X and let's not forget the design of NeXTStep. ... and how currently popular they[NeXT] are. ;- Yeah, about as popular as, say, FreeBSD? Bill, you know popularity and even success in the market have little to do with competence. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
Jordan Hubbard wrote: Yeah, but in what sense is that use of Mach a serious microkernel, if it's only got one server: BSD? I've never understood the point of that sort of use. It makes sense for a QNX or GNU/Hurd or minix or Amoeba style of architecture, but how does Mach help Apple, instead of using the bottom half of BSD as well as the top half? That's actually a much better question and one I can't really answer. One theory might be that the NeXT people were simply Microkernel bigots for no particularly well-justified reason and that is simply that. Another theory might be that they were able to deal with the machine-dependent parts of Mach far more easily given its comparatively minimalist design and given their pre-existing expertise with it. Another theory, sort of related to the previous one, is that Apple has some sort of plans for the future which they're not currently sharing where Mach plays some unique role. Does the older MacOS compatibility mode (is this the "blue box"?) run on the BSD-Lite server, or directly on Mach? That seems a likely starting point. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Writing Device Drivers
Sergey Babkin wrote: David Preece wrote: At 13:02 17/12/00 +, you wrote: Does anyone have any good tips to get started / HowTo's, or some simple examples that will give me knowledge like the PC Speaker or something simple like that? This is turning into a FAQ, but don't worry about it. The usual answer is to take one of the existing drivers and work out what it does. There's also Look at the DaemonNews (www.daemonnews.org), the Blueprints column. If I remember the months correctly, in the July 2000 issues there is an introduction into FreeBSD device drivers by Alexander Langner, and in June and August issues there are my articles on CAM (SCSI) drivers and ISA device drivers respectively. There also were articles on the Netgraph networking subsystem and on writing drivers as modules. I believe that these articles have been turned into sections of the Handbook as well but I'm not sure where exectly in Handbook they are. It's about time for an article index at DN, isn't it? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
In message [EMAIL PROTECTED], Warner Losh writes: Number 2. ANSI-C (aka c89) requires that free(NULL) work. We shouldn't go out of our way to pander to those machines where it doesn't. The reason why this is so is that it is legal for realloc(ptr, 0): to return either a NULL pointer or a real pointer, and to remain consistent, the following sequence should always be legal: ptr = malloc(foo); ptr = realloc(foo, bar); free(ptr); -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
