On 2012/08/16 01:49, Konstantin Belousov wrote:
On Wed, Aug 15, 2012 at 07:40:04AM +0800, David Xu wrote:
On 2012/08/15 05:09, Jilles Tjoelker wrote:
On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote:
But in real word, pthread atfork handlers are not async-signal safe,
they mostly do mu
On 2012/08/16 07:57, David Xu wrote:
On 2012/08/16 01:46, Konstantin Belousov wrote:
On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote:
You are requiring the thread library to implement such a mutex
and other locks, that after vfork(), the mutex and other lock types
must
still work acr
On 2012/08/16 01:46, Konstantin Belousov wrote:
On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote:
You are requiring the thread library to implement such a mutex
and other locks, that after vfork(), the mutex and other lock types must
still work across processes, the PTHREAD_PROCESS_PRIVA
On Mon, Aug 13, 2012 at 9:28 PM, Julian Elischer
wrote:
> you will also have to change PID_MAX (spelling?) to be 6
> I have considered making this a tunable..
> If you don't then the shell in the 1.1.5.1 environment will not be able to
> handle when a child
> get s a pid of > 16 bits and it w
On 08/15/12 11:54, Poul-Henning Kamp wrote:
In message
, Adrian Chadd writes:
Holy. Crap. 17 seconds?
Can we please go back to having it take this long? please?
386BSD was even better, and I have a machine that boots it in less
than 15 seconds from power-on...
A Sun 3-50 with a 15.7MHz 68020
On Wed, Aug 15, 2012 at 12:30 PM, Adrian Chadd wrote:
> On 15 August 2012 11:54, Poul-Henning Kamp wrote:
>> In message
>>
>> , Adrian Chadd writes:
>>>Holy. Crap. 17 seconds?
>>>
>>>Can we please go back to having it take this long? please?
>>
>> 386BSD was even better, and I have a machine th
In message
, Adrian Chadd writes:
>Holy. Crap. 17 seconds?
>
>Can we please go back to having it take this long? please?
386BSD was even better, and I have a machine that boots it in less
than 15 seconds from power-on...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
All,
Asking this here as I don't see a mailing list specifically devoted to
build/release
issues and because I think it is a little beyond the standard -question genre.
Our product here is based on FreeBSD (currently FreeBSD 9/STABLE) and it has
reached
the stage where we need to create our own
On 15 August 2012 11:54, Poul-Henning Kamp wrote:
> In message
>
> , Adrian Chadd writes:
>>Holy. Crap. 17 seconds?
>>
>>Can we please go back to having it take this long? please?
>
> 386BSD was even better, and I have a machine that boots it in less
> than 15 seconds from power-on...
:-)
Embe
Holy. Crap. 17 seconds?
Can we please go back to having it take this long? please?
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubsc
On Wed, Aug 15, 2012 at 07:40:04AM +0800, David Xu wrote:
> On 2012/08/15 05:09, Jilles Tjoelker wrote:
> >On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote:
> >>But in real word, pthread atfork handlers are not async-signal safe,
> >>they mostly do mutex locking and unlocking to keep consis
On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote:
> You are requiring the thread library to implement such a mutex
> and other locks, that after vfork(), the mutex and other lock types must
> still work across processes, the PTHREAD_PROCESS_PRIVATE type of
> mutex and other locks now need t
On Wed, Aug 15, 2012 at 03:55:37AM -0700, Julian Elischer wrote:
> On 8/15/12 3:29 AM, Julian Elischer wrote:
> >On 8/14/12 6:07 AM, Konstantin Belousov wrote:
> >>On Mon, Aug 13, 2012 at 06:28:46PM -0700, Julian Elischer wrote:
> >>>On 8/13/12 3:33 PM, Dan Plassche wrote:
> Konstantin,
>
On Wednesday, August 15, 2012 4:46:28 am Garrett Cooper wrote:
> On Wed, Aug 15, 2012 at 1:27 AM, Daniel Braniss wrote:
> > hi,
> > this host has to disks:
> > sa0> gpart show
> > => 34 976773101 ada0 GPT (465G)
> > 34128 1 freebsd-boot (64k)
> > 162419
/* This prints 04030201 */
printf ("b= %0X \n", *b);
all is OK, you did this probably on x86 CPU which is little endian. on
powerpc it would be 01020304 as it is big endian.
to write endian independent code:
man htonl
all these are macros actually.
"network order" is big endian. so eg htonl
On 8/15/12 3:29 AM, Julian Elischer wrote:
On 8/14/12 6:07 AM, Konstantin Belousov wrote:
On Mon, Aug 13, 2012 at 06:28:46PM -0700, Julian Elischer wrote:
On 8/13/12 3:33 PM, Dan Plassche wrote:
Konstantin,
My apologies for any confusion. Your patch solved the problem on
8.2. Static and dyn
On 8/14/12 6:07 AM, Konstantin Belousov wrote:
On Mon, Aug 13, 2012 at 06:28:46PM -0700, Julian Elischer wrote:
On 8/13/12 3:33 PM, Dan Plassche wrote:
Konstantin,
My apologies for any confusion. Your patch solved the problem on
8.2. Static and dynamic a.out binaries from 1.1.5.1 are working
On 2012-Aug-15 10:33:46 +0200, Daniel Grech wrote:
>Hi,
>
>I have what is probably a really elementary question but I can't seem to
>figure it out. In the following snippet of code, why is it that a and b do
>not have the same value in the end ? :
See http://en.wikipedia.org/wiki/Endian
>Im ask
On 08/15/2012 10:33 AM, Daniel Grech wrote:
> Hi,
>
> I have what is probably a really elementary question but I can't seem to
> figure it out. In the following snippet of code, why is it that a and b do
> not have the same value in the end ? :
>
> #define uint32_t unsigned int
> #define uint16_t
On Wed, Aug 15, 2012 at 1:27 AM, Daniel Braniss wrote:
> hi,
> this host has to disks:
> sa0> gpart show
> => 34 976773101 ada0 GPT (465G)
> 34128 1 freebsd-boot (64k)
> 1624194304 2 freebsd-ufs (2.0G)
> 4194466 33554432 3 freebsd-swap
hi,
this host has to disks:
sa0> gpart show
=> 34 976773101 ada0 GPT (465G)
34128 1 freebsd-boot (64k)
1624194304 2 freebsd-ufs (2.0G)
4194466 33554432 3 freebsd-swap (16G)
37748898 939024237 4 freebsd-zfs (447G)
=> 34
Hi,
I have what is probably a really elementary question but I can't seem to
figure it out. In the following snippet of code, why is it that a and b do
not have the same value in the end ? :
#define uint32_t unsigned int
#define uint16_t unsigned short
#define uint8_t unsigned char
#define uint6
22 matches
Mail list logo
