| From | Subject | Date |
|---|---|---|
| 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 day | today | next day |
|---|---|---|
| July 17, 2008 | July 18, 2008 | July 19, 2008 |
