Re: Announcing PathDB
C. Bergström wrote: Apologies.. I didn't really expect anyone to know about it. To me the best way to describe it is similar to gdb, but much cleaner codebase. Might be more effective to offer this to the llvm community, I would have thought. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
pxeboot and http
Is the ability for pxeboot to load from an HTTP source merged - or due to be merged? It was a gsoc from 2007 wasn't it? James ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: BDB corrupt
Kurt J. Lidl wrote: This catapults back into the arena of stuff that isn't in the base system. Not to mention I'm not sure that the Oracle BDB license would allow bundling in the OS as a binary. I doubt it, but that's a different bikeshed to paint :-) Is the LGPL of QDBM and TokyoCabinet also a problem? Could even try grovelling with Mikio? (Partially joking there. I assume he chose LGPL because he wants it that way, but people have been known to change licenses for a base system - like this http://blogs.sun.com/aalok/entry/lzma_on_opensolaris) And is the objection to SQL such the sqlite is really out of the running? Anyway, in this case, would writing an RPC server to own the data kill the performance? It should be easier to write something that can save the database atomically and index it in-core. It could be started on demand and shut down after a short inactivity, a bit like tibco's rvd. There are known problems with certain keys corrupting the DB 1.8x series code. In fact, the release of the 1.86 was an attempt to solve this problem when the KerberosV people at MIT found a repeatable key insert sequence that would corrupt things. (Or at least that's what I remember, it was a long time ago, and I might have the details wrong.) Have to say its a little concerning that such 'mature' code is actually problematic. Particularly since I'm not aware of a non-LGPL alternative. Do you have anything by way of a pointer? Google didn't help me here. James ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kqueue and libev
Kip Macy wrote: he's just plain misinforme Until we know what he is referring to we can't actually say that. -Kip OK he said I could post from our private email so here goes. There were bits in and around relating to the Solaris /dev/poll support (and the mechanism's limitations) which I've elided. I think the most telling thing is probably that drivers need to provide support and that a single mechanism in the driver doesn't support select and poll at the same time - which I guess lines up with the reported failure with USB serial. Does kqueue work with USB for example? How about an AIO request to read from a USB endpoint? It may well just be a case of 'fessing up to system limitations. James Compile and install rxvt-unicode on freebsd and run it with: urxvt # works, uses select (or maybe poll) LIBEV_FLAGS=8 urxvt # acts weird, uses kqueue (note: only works when urxvt isn't set[gu]id) The typical symptoms are either delayed notificatrions, no notifications at all or _continuous_ notifications and read failing with EAGAIN. Here is a ktrace showing the latter: http://ue.tst.eu/45eb8a3c3e812933cbe3172af2ee4a6c.txt kqueue works well with sockets (or with about anything on netbsd), but fails on more exotic types such as ptys. (I test on Freebsd 6.2 RELEASE, but got reports about problems with earlier and later versions, too, as well as on openbsd (which I didn't verify) and on darwin (which is completely broken)). You normally don't get useful writeable/readable state for files, No, I only want the same readyness notifications as with select or poll, as is documented in the manpage. (even on platforms where kqueue works this requires some heuristics and workarounds with kqueue due to design limitations (for example problems with close() or fork() that force constant rearming), but thats common in interfaces like kqueue, and by now well understood and handled by libev). Actually, until recently it was broken on pipes. We've never received any PRs to that effect so there is no way of knowing. You'll have better luck asking the author himself. Well, one should better document the types with which it works (which on freebsd apparently includes sockets and nothing else). I also think one should rethink the internal design if every driver needs its own kqueue support, as that will always force kqueue into a second-class citizen not suitable as replacement for select, as it's unreasonable to expect kqueue to just work when its so little used and requires such a high maintainance (linux' epoll for example works fine with everything because it doesn't require drivers to support epoll specifically, so it is unlikely that epoll fails when select would work for example, which is the case on freebsd and darwin). The fact that it works fine on everything I threw at it on netbsd is probably not the result of better design, but more better maintainance, so I wouldn't be surprised if some future version of netbsd failed in similar ways (OTOH, in the past, netbsd consistently was the less buggy platform regardless of topic, wether it was threads, ptys or kqueue, so I might get quite disappointed if that happened :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kqueue and libev
Kip Macy wrote: Do you have a set of regression tests for libev? It sounds like they would worth having to regression test kqueue. I would have thought that libevent and libev should both the checked against kqueue. Also APR and everything else that has support. I'm not the author of libev though, so I'm the wrong guy to ask. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
kqueue and libev
Any idea what the author of libev is on about here (from http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod): unsigned int ev_recommended_backends () Return the set of all backends compiled into this binary of libev and also recommended for this platform. This set is often smaller than the one returned by |ev_supported_backends|, as for example kqueue is broken on most BSDs and will not be autodetected unless you explicitly request it (assuming you know what you are doing). and |EVBACKEND_KQUEUE| (value 8, most BSD clones) Kqueue deserves special mention, as at the time of this writing, it was broken on all BSDs except NetBSD (usually it doesn't work with anything but sockets and pipes, except on Darwin, where of course its completely useless). For this reason its not being autodetected unless you explicitly specify it explicitly in the flags (i.e. using |EVBACKEND_KQUEUE|). It looks like a decent library, but these comments seem unfortunate. Does anyone know what the author is concerned about? James ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
A question about swapping
I'm looking for an operating system that I can use to build some diskless workstations. I'd really like to be able to support swapping. Is it feasible to enable swap to any remote file or remote block device with FreeBSD - without risking a deadlock? Linux seems to be prone to deadlock. I don't know about Solaris. I see that 7.0 will have an iSCSI initiator - is there any work underway to support reliable swap against an iSCSI target? James ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
