freebsd-hackers mailing list

FromSubjectsort iconDate
Randy Bush
Re: Sysinstall is still inadequate after all of these years
oh, i agree completely. my point was that i seem to invoke sysinstall when standalone would be more 'normal.' and then i was pointed to sade(8) :) . randy _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Jul 17, 5:21 pm 2008
Vincent Hoffman
Re: Sysinstall is still inadequate after all of these years
Ahh thats nice to know, might be worth adding to the handbook, I used to use /usr/ports/sysutils/sfdisk but somethng in base beats it. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Jul 18, 2:46 am 2008
John Baldwin
Re: Sysinstall is still inadequate after all of these years
Yes, I have found it nicer than raw bsdlabel in the past, but I think it should be a standalone tool (diskpart or some such) that manages that and that the installer should use that tool rather than the installer having a disk partitioning sub-personality. -- John Baldwin _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to ...
Jul 17, 5:13 pm 2008
Jilles Tjoelker
Re: Pls sanity check my semtimedop(2) implementation
In your implementation, the SIGALRM signal may happen before you even call semop(2). If so, most likely the semop(2) will hang arbitrarily long. A somewhat dirty fix is to put a nonzero value into it_interval. This will ensure that if a signal is missed another one will be generated quickly. You might be able to fix this using setjmp/longjmp, but this is neither pretty nor efficient. Another dirty fix is to try non-blocking semop(2) several times with This does not fix the inherent ...
Jul 18, 8:58 am 2008
Michael B Allen
Re: Pls sanity check my semtimedop(2) implementation
I can't ask my customers to patch their systems. But I'll keep it in mind for the future. I don't recall why I chose System V semaphores originally. I think process-shared semantics in the POSIX implementations where not mature at the time. I would love to move away from System V semaphores. It's all too easy to leak them and trying to clean up on restart is dangerous. Mike _______________________________________________ freebsd-hackers@freebsd.org mailing ...
Jul 17, 6:54 pm 2008
John Baldwin
Re: Pls sanity check my semtimedop(2) implementation
POSIX semaphores (sem_open(3), sem_create(3), etc.) do have a sem_timedwait(3). However, POSIX semaphores have several bugs in 6.x and 7.x (they should work a lot better in 8). If you want I can give you a patch for 6.x or 7.x that backports the 8.x POSIX semaphores. -- John Baldwin _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to ...
Jul 17, 5:15 pm 2008
Sean C. Farley
Re: Pls sanity check my semtimedop(2) implementation
On Thu, 17 Jul 2008, Michael B Allen wrote: It is my understanding that process-shared is not currently supported at least in 7. Does anyone know if there is any intention of this being eventually supported? I have needed this in the past but do not need it at the moment. It would be nice to have someday. Sean -- scf@FreeBSD.org _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To ...
Jul 18, 9:27 am 2008
Daniel O'Connor
Re: Can I change the device of the "/" mount point at bo ...
OK. I think using GEOM is the "Right Way" in FreeBSD for this. =2D-=20 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
Jul 17, 6:25 pm 2008
Patrick
crypto(9) and maxoplen
Hello, In the "opencrypto framework" the function crypto_register() has an argument 'maxoplen'. http://fxr.watson.org/fxr/source/opencrypto/crypto.c#L625 Does somebody know what was the goal of this parameter? It is not used by the framework. The man page of crypto(9) says : For each algorithm the driver supports, it must then call crypto_register(). The first two arguments are the driver and algorithm identifiers. The next two arguments specify the largest possible operator length ...
Jul 18, 3:58 pm 2008
previous daytodaynext day
July 17, 2008July 18, 2008July 19, 2008