Re: Linux version of libusb that works with FreeBSD
On Mon, 17 Dec 2007 16:26:58 +1030 "Daniel O'Connor" <[EMAIL PROTECTED]> wrote: > I am wondering if anyone has tried building such a beast? > ie a Lunux libusb that will be able to access devices in FreeBSD.. Well, the devel/libusb port builds out of the box for me. It's used by a number of image grabbing tools (gphoto, sane and hplib), and by tools like nut for talking to UPS systems. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Linux version of libusb that works with FreeBSD
I am wondering if anyone has tried building such a beast? ie a Lunux libusb that will be able to access devices in FreeBSD.. The reason I'd like it is that I want to use this http://rmdir.de/~michael/xilinx/ in FreeBSD so I can talk to a USB JTAG cable. The thing I am not sure about is how ioctl's would get mangled on the way through. I guess the other approach would be to use a standard Linux libusb but emulate the device tree it uses in Linux.. Would be a lot of work though I think. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: Disk sync at shutdown and fusefs filesystems
On Mon, 17 Dec 2007 02:21:53 +0100 Csaba Henk <[EMAIL PROTECTED]> wrote: > >> They have already discovered issues with system shutdown on Linux, and > >> Miklos has implemented a solution for this dubbed as "synchronous > >> umount". According to this, the protocol is enhanced with a new message > >> called DESTROY. Upon unmounting the fs, the kernel sends a DESTROY to > >> the daemon and waits for answer. That is, unmount(2) won't complete > >> until the fs says to the kernel "OK, I'm done". > >> [...] > > Hmm, I don't know much of this, but isn't the Linux problem related to > > flushing its own block device cache? In FreeBSD it doesn't exist (i.e. > > ublio is only user-space), so I wonder if just unmounting before > > shutdown solves the issue. I mean, does the kernel still keep > > information after a FUSE filesystem is unmounted? > > > > Please correct me if I'm wrong. > > > > At least the currently discussed trick only works because it waits a few > > seconds after unmounting to let it flush the cache (but I think it's a > > common fact that filesystems get registered/unregistered with a small > > delay, and may not be related to that). > > The point in synch umount is that you don't need to wait for an ad hoc > amount of time in order to have the various caches flushed / media > sync'd -- it enables the filesystem daemon itself to notify the umount > procedure that it's done and the world can go on. > > The exact nature of caches (userspace / in-kernel) doesn't really make a > difference from this POV. (Implementing the appropriate synchronization > mechanisms is up to the fs daemon.) > I see, thanks for the clarification. > >> - Some "got hung in unmount" issues are to be sorted out (these > >>appeared on Linux, and they might or might not appear on FreeBSD). > >> > > > > Never seen this, but also never unmounted at shutdown before. I have a > > patch for it (see thread). Then we could easily see if it get stalled > > at shutdown (or when manually stopping the rc.d script). > > Of course you've never seen this! -- these have appeared as consequences > of the synchronous umount (ie., the DESTROY message) which is not yet > implemented on FreeBSD. > That's logical. I missed the point. > The actual question is whether it is worth to implement it. For me it > seems "yes", but I don't know the ins and outs of the FreeBSD > init/shutdown system, that's why I'd like to hear the opinion of people > like you about this before I go and code it. > I'm not in the kernel side, but I think it's the correct thing to do. The kernel syncer does the same with other filesystems, so... > Whether hangs occur or not if fuse4bsd does sync umount is not that > important. I mean, first I would code a basic implementation of DESTROY > (that's pretty simple to do!) and we'd see how well that works and if we > see problems I try to tune the implementation. That's just business as > usual. > For what you said, we won't know if there are hangs until we have an implementation of DESTROY. So this will be attended later as you said. > The next issue is more important... > > >> - Security issue: with synch unmount, any user who can mount (w/ synch > >>unmount), is capable of making the unmount stuck (which is easy to > >>fix when the system is up -- just kill the fs daemon -- but can > >>make the shutdown process hopelessly stuck). So we'd have to > >>decide who/when shall be able to do mounts for which the unmount is > >>synchronous. (The current criteria for this on Linux -- ie., > >>is the fuseblk fs variant being used? -- is N/A to FreeBSD for > >>reasons which are OT here. However, Miklos decided to > >>change this so that sych unmount will be tied to the "allow_other" > >>option, which is tied to root privileges, and does make sense > >>on FreeBSD, too. I'd be happy to hear more suitable criteria. > >> > > > > This would depend on the previous point. > > It's more important to specify a suitable security policy -- who/when > should be capable of mounting an fs in a way so that the umount will > be synchronous? (Short term for this: "mounting with synch umount"). > > I think it's quite a "standalone" question, it depends on nothing else. - Some "got hung in unmount" issues are to be sorted out (these appeared on Linux, and they might or might not appear on FreeBSD). IIRC you are saying that any user could make umount hang. And you said this is an unintended behavior caused by the implementation, which appeared on Linux and we don't know if it will happen on FreeBSD. Otherwise the daemon would synchronize the fs and let umount return normally, and this wouldn't happen, right? If this always happens then what is the difference between happening on a root/non-root mount, as it will hang anyways? If I missed the point again please correct me, and clarify the following: Does the hang (point 2)/umount stuck (point 3) issues consist of the same (I assumed so)
Re: Disk sync at shutdown and fusefs filesystems
On 2007-12-12, Alejandro Pulver <[EMAIL PROTECTED]> wrote: > On Wed, 12 Dec 2007 03:00:07 +0100 > Csaba Henk <[EMAIL PROTECTED]> wrote: > >> On 2007-12-11, Alejandro Pulver <[EMAIL PROTECTED]> wrote: >> > The problem with NTFS-3G (and all other FUSE based drivers maybe) is >> > that it doesn't flush the cache data to the disk at shutdown, but it >> > does when unmounted (and I guess this doesn't happen automatically). I >> > noticed this when files I write before manually unmounting persist, and >> > otherwise sometimes they don't. >> >> I just happen to discuss this issue with Szaka (ntfs-3g developer) and >> Miklos Szeredi (FUSE developer). At least, we're discussing something >> which might have a relevance here. >> >> They have already discovered issues with system shutdown on Linux, and >> Miklos has implemented a solution for this dubbed as "synchronous >> umount". According to this, the protocol is enhanced with a new message >> called DESTROY. Upon unmounting the fs, the kernel sends a DESTROY to >> the daemon and waits for answer. That is, unmount(2) won't complete >> until the fs says to the kernel "OK, I'm done". >> >> This was introduced in the following commit (as seen in my HG mirror): >> >> http://mercurial.creo.hu/repos/fuse-hg/?rev/a5df6fb4a0e6 >> >> and it's already included in the current sysutils/fusefs-libs port. >> >> And it wouldn't be hard to add kernel side support for FreeBSD. There >> are some questions though: >> >> - Do you think it could be actually useful for solving the shutdown >>issue on FreeBSD? >> > > Hmm, I don't know much of this, but isn't the Linux problem related to > flushing its own block device cache? In FreeBSD it doesn't exist (i.e. > ublio is only user-space), so I wonder if just unmounting before > shutdown solves the issue. I mean, does the kernel still keep > information after a FUSE filesystem is unmounted? > > Please correct me if I'm wrong. > > At least the currently discussed trick only works because it waits a few > seconds after unmounting to let it flush the cache (but I think it's a > common fact that filesystems get registered/unregistered with a small > delay, and may not be related to that). The point in synch umount is that you don't need to wait for an ad hoc amount of time in order to have the various caches flushed / media sync'd -- it enables the filesystem daemon itself to notify the umount procedure that it's done and the world can go on. The exact nature of caches (userspace / in-kernel) doesn't really make a difference from this POV. (Implementing the appropriate synchronization mechanisms is up to the fs daemon.) >> - Some "got hung in unmount" issues are to be sorted out (these >>appeared on Linux, and they might or might not appear on FreeBSD). >> > > Never seen this, but also never unmounted at shutdown before. I have a > patch for it (see thread). Then we could easily see if it get stalled > at shutdown (or when manually stopping the rc.d script). Of course you've never seen this! -- these have appeared as consequences of the synchronous umount (ie., the DESTROY message) which is not yet implemented on FreeBSD. The actual question is whether it is worth to implement it. For me it seems "yes", but I don't know the ins and outs of the FreeBSD init/shutdown system, that's why I'd like to hear the opinion of people like you about this before I go and code it. Whether hangs occur or not if fuse4bsd does sync umount is not that important. I mean, first I would code a basic implementation of DESTROY (that's pretty simple to do!) and we'd see how well that works and if we see problems I try to tune the implementation. That's just business as usual. The next issue is more important... >> - Security issue: with synch unmount, any user who can mount (w/ synch >>unmount), is capable of making the unmount stuck (which is easy to >>fix when the system is up -- just kill the fs daemon -- but can >>make the shutdown process hopelessly stuck). So we'd have to >>decide who/when shall be able to do mounts for which the unmount is >>synchronous. (The current criteria for this on Linux -- ie., >>is the fuseblk fs variant being used? -- is N/A to FreeBSD for >>reasons which are OT here. However, Miklos decided to >>change this so that sych unmount will be tied to the "allow_other" >>option, which is tied to root privileges, and does make sense >>on FreeBSD, too. I'd be happy to hear more suitable criteria. >> > > This would depend on the previous point. It's more important to specify a suitable security policy -- who/when should be capable of mounting an fs in a way so that the umount will be synchronous? (Short term for this: "mounting with synch umount"). I think it's quite a "standalone" question, it depends on nothing else. If a FUSE fs is mounted with synch umount its daemon can block the umount command/syscall, and therefore it can probably block the whole shutdown sequence (killing the
RE: kqueue and libev
Julian Elischer wrote: > Julian Elischer wrote: > > James Mansion wrote: > >> [ On the libev being unhappy with kqueue ] > >> ... > >> It looks like a decent library, but these comments seem > unfortunate. > >> Does anyone know what the author is concerned about? > > > > he's just plain misinformed > > > > kqueue works well with aio to files and raw devices for > example. (Only using AIO really makes sense in these cases > anyhow, so I've never really tried using kqueue with non-aio calls.) It also depends what version of FreeBSD. For example, in FreeBSD 4, kqueue was non-functional with USB serial devices. I ran into that exact problem with kqueue when porting my event library. Problems like that can make life difficult for a library author; having a special case for one kind of handle is a pain, to the point of leading to comments like this. Of course, in this case the best thing to do is to ask the author, and to see if the situation has changed. Regards, Jan Mikkelsen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Behaviour of send()
Hi, If the SO_SNDBUF option is set on a TCP socket with some size N, and assuming nothing is queued for sending yet, is it safe to assume send() won't block while attempting to send a block whose size is <= N, even if the socket is in "blocking" mode? signature.asc Description: OpenPGP digital signature
Re: kqueue and libev
On Dec 15, 2007, at 08:47 , Kip Macy wrote: On 12/15/07, James Mansion <[EMAIL PROTECTED]> wrote: 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 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. -Kip How recently? I have been using kqueue with pipes in several programs for the last year or so. Bert JW Regeer
