Re: Freebsd on the sun x4440

[Erich Dollansky]

Hi,

I would like to suggest to try 8.2.

It is my experience that the different version behave very different on the 
same hardware. It does not mean that the newer version is the better. As an 
example, I have a machine here on 7.x as 8.0 did not support the USB hardware 
found. After a machine works with a branch, I will stick with this branch on 
the specific machine until the end of support for the branch. This make life 
much easier and keeps surprises away.

On Thursday 17 May 2012 07:34:50 Mark Saad wrote:
> All
>   I am setting up 3 sun x4440 with freebsd 7.3 amd64 . The severs have 4x 
> 4-core opterons and 128G of ram each . Once the servers boot they are a good 
> fit for what we are doing and preform well . The odd thing I am seeing is a 
> long delay in boot up . Once in the initial loading of the kernel at the "|" 
> for 1-2 mins . Then again shortly after printing the kernel banner "freebsd 
> 7.3-release etc etc etc" .  This delay is about 1-2 mins as well.  So my 
> question does any one know what I could do to speed up the boot up ? I 
> suspect the first delay is due to a serial  device probe the second is a 
> mystery . also the bios load up time is about 5 mins on this box does anyone 
> have any ideas on speeding that up ?

Does this machine have SCSI or SAS hardware? If the controllers are there but 
not drives are installed, a GENERIC kernel will wait for some time for SCSI to 
settle. If you deactivate SCSI or reduce the waiting time, at least a part of 
the problem is solved.

Erich
> 
> 
> mark saad 
> Nonesuch@longcount.org___
> 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"
> 
> 
___
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: [rfc] a few kern.mk and bsd.sys.mk related changes

[Alexander Best]

On Sat May 28 11, Alexander Best wrote:
> On Sat May 28 11, Bruce Cran wrote:
> > On Sat, May 28, 2011 at 06:23:26PM +, Alexander Best wrote:
> > > 
> > > well i'm not an expert on this. but are we 100% sure that a kernel on 
> > > amd64
> > > compiled with -O2 frename-registers can be debugged the same way as one 
> > > with
> > > -O? if that is the case: sure...-O2 is fine. ;)
> > > 
> > > however i've often read messages - mostly by bruce evans - claiming that
> > > anything greater than -O will in fact decrease a kernel's ability to be
> > > debugged just as well as a kernel with -O.
> > > 
> > 
> > The critical option when -O2 is used is -fno-omit-frame-pointers, since 
> > removing
> > frame pointers makes debugging impossible (on i386). With -O2 code is moved 
> > around and
> > removed, so debugging is more difficult, but can still provide useful
> > information.
> 
> how about making -fno-omit-frame-pointers mandatory for all builds with an
> optimisation level higher than -O?

man this is confusing. why must the freebsd make skeleton be so complicated. :(
it seems -fno-omit-frame-pointers gets set in sys/conf/Makefile.amd64 and
sys/conf/Makefile.powerpc already. also for modules in sys/conf/kmod.mk. i
guess somebody with a better in deth knowledge should investigate this matter.

this is a bit too complicated for me.

cheers.
alex

> 
> something like
> 
> .if !empty(COPTFLAGS:M-O[234sz]) && empty(COPTFLAGS:M-fno-omit-frame-pointers)
> COPTFLAGS+= -fno-omit-frame-pointers
> .endif
> 
> (-O4 and -Oz are clang specific, but it won't hurt having them in there)
> 
> cheers.
> alex
> 
> > 
> > -- 
> > Bruce Cran
> 
> -- 
> a13x

-- 
a13x
___
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: [rfc] a few kern.mk and bsd.sys.mk related changes

[Alexander Best]

On Sat May 28 11, Bruce Cran wrote:
> On Sat, May 28, 2011 at 06:23:26PM +, Alexander Best wrote:
> > 
> > well i'm not an expert on this. but are we 100% sure that a kernel on amd64
> > compiled with -O2 frename-registers can be debugged the same way as one with
> > -O? if that is the case: sure...-O2 is fine. ;)
> > 
> > however i've often read messages - mostly by bruce evans - claiming that
> > anything greater than -O will in fact decrease a kernel's ability to be
> > debugged just as well as a kernel with -O.
> > 
> 
> The critical option when -O2 is used is -fno-omit-frame-pointers, since 
> removing
> frame pointers makes debugging impossible (on i386). With -O2 code is moved 
> around and
> removed, so debugging is more difficult, but can still provide useful
> information.

how about making -fno-omit-frame-pointers mandatory for all builds with an
optimisation level higher than -O?

something like

.if !empty(COPTFLAGS:M-O[234sz]) && empty(COPTFLAGS:M-fno-omit-frame-pointers)
COPTFLAGS+= -fno-omit-frame-pointers
.endif

(-O4 and -Oz are clang specific, but it won't hurt having them in there)

cheers.
alex

> 
> -- 
> Bruce Cran

-- 
a13x
___
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: [rfc] a few kern.mk and bsd.sys.mk related changes

[Bruce Cran]

On Sat, May 28, 2011 at 06:23:26PM +, Alexander Best wrote:
> 
> well i'm not an expert on this. but are we 100% sure that a kernel on amd64
> compiled with -O2 frename-registers can be debugged the same way as one with
> -O? if that is the case: sure...-O2 is fine. ;)
> 
> however i've often read messages - mostly by bruce evans - claiming that
> anything greater than -O will in fact decrease a kernel's ability to be
> debugged just as well as a kernel with -O.
> 

The critical option when -O2 is used is -fno-omit-frame-pointers, since removing
frame pointers makes debugging impossible (on i386). With -O2 code is moved 
around and
removed, so debugging is more difficult, but can still provide useful
information.

-- 
Bruce Cran
___
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: [rfc] a few kern.mk and bsd.sys.mk related changes

[Alexander Best]

On Sat May 28 11, Alexander Best wrote:
> On Sat May 28 11, Pan Tsu wrote:
> > Alexander Best  writes:
> > 
> > > On Fri May 27 11, Alexander Best wrote:
> > >> On Fri May 27 11, Warner Losh wrote:
> > >> > These look generally good.  Just one thing I had a question on:
> > >> > 
> > >> >  #
> > >> > +# Enable FreeBSD kernel-specific printf format specifiers. Also 
> > >> > instruct gcc to
> > >> > +# enable some diagnostics, which make it easier to pinpoint tinderbox 
> > >> > failures.
> > >> > +CFLAGS+=  -fformat-extensions -fdiagnostics-show-option
> > >> > +
> > >> > 
> > >> > Does this put sand in the gears of clang support?
> > >
> > > i've improved the above comment so as to note that clang won't be 
> > > affected by
> > > -fdiagnostics-show-option. the new patch is available here:
> > >
> > > http://people.freebsd.org/~arundel/patches/kern.mk-bsy.sys.mk.patch
> > >
> > > another "issue" i've come across is the fact that on amd64, -O2 is always 
> > > being
> > > set, no matter, if debugging is enabled or disabled. i think amd64 should 
> > > also
> > > (just like all the other archs) be using -O, when debugging was enabled.
> > 
> > Any reason a kernel with symbols (DEBUG) *must* be pessimized to -O1 level?
> > Looking at r140606 it's not clear how symbols are related to a bump
> > from -O1 to -O2 for non-amd64 archs. And -RELEASE kernels since at least
> > 6.0R have `makeoptions DEBUG=-g' uncommented in GENERIC.
> 
> well i'm not an expert on this. but are we 100% sure that a kernel on amd64
> compiled with -O2 frename-registers can be debugged the same way as one with
> -O? if that is the case: sure...-O2 is fine. ;)
> 
> however i've often read messages - mostly by bruce evans - claiming that
> anything greater than -O will in fact decrease a kernel's ability to be
> debugged just as well as a kernel with -O.

ok. so here are two seperate patches:

http://people.freebsd.org/~arundel/patches/kern.mk-bsd.sys.mk.patch

^^ this one will trigger -O on amd64, when debugging was enabled.

http://people.freebsd.org/~arundel/patches/kern.mk-bsd.sys.mk-O2.patch

^^ this one will leave the semantics as they are, so even when debugging was
enabled, -O2 gets set under amd64.

cheers.
alex

> 
> cheers.
> alex
> 
> > 
> > > changing this is quite easy. so if people think this is something worth
> > > changing i can integrate it into my existing patch.
> 
> -- 
> a13x

-- 
a13x
___
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: [rfc] a few kern.mk and bsd.sys.mk related changes

[Alexander Best]

On Sat May 28 11, Pan Tsu wrote:
> Alexander Best  writes:
> 
> > On Fri May 27 11, Alexander Best wrote:
> >> On Fri May 27 11, Warner Losh wrote:
> >> > These look generally good.  Just one thing I had a question on:
> >> > 
> >> >  #
> >> > +# Enable FreeBSD kernel-specific printf format specifiers. Also 
> >> > instruct gcc to
> >> > +# enable some diagnostics, which make it easier to pinpoint tinderbox 
> >> > failures.
> >> > +CFLAGS+=-fformat-extensions -fdiagnostics-show-option
> >> > +
> >> > 
> >> > Does this put sand in the gears of clang support?
> >
> > i've improved the above comment so as to note that clang won't be affected 
> > by
> > -fdiagnostics-show-option. the new patch is available here:
> >
> > http://people.freebsd.org/~arundel/patches/kern.mk-bsy.sys.mk.patch
> >
> > another "issue" i've come across is the fact that on amd64, -O2 is always 
> > being
> > set, no matter, if debugging is enabled or disabled. i think amd64 should 
> > also
> > (just like all the other archs) be using -O, when debugging was enabled.
> 
> Any reason a kernel with symbols (DEBUG) *must* be pessimized to -O1 level?
> Looking at r140606 it's not clear how symbols are related to a bump
> from -O1 to -O2 for non-amd64 archs. And -RELEASE kernels since at least
> 6.0R have `makeoptions DEBUG=-g' uncommented in GENERIC.

well i'm not an expert on this. but are we 100% sure that a kernel on amd64
compiled with -O2 frename-registers can be debugged the same way as one with
-O? if that is the case: sure...-O2 is fine. ;)

however i've often read messages - mostly by bruce evans - claiming that
anything greater than -O will in fact decrease a kernel's ability to be
debugged just as well as a kernel with -O.

cheers.
alex

> 
> > changing this is quite easy. so if people think this is something worth
> > changing i can integrate it into my existing patch.

-- 
a13x
___
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: Active slice, only for a next boot

[Julian Elischer]

On 5/28/11 11:10 AM, Julian Elischer wrote:

On 5/28/11 4:06 AM, Chris Rees wrote:



On 28 May 2011 10:04, "Julian Elischer" > wrote:

>
> On 5/27/11 11:34 AM, Warner Losh wrote:
>>
>> On May 27, 2011, at 10:47 AM, rank1see...@gmail.com 
 wrote:

>>
>>> - Original Message -
>>> From: Alexander Best>

>>> To: rank1see...@gmail.com 
>>> Cc: hack...@freebsd.org 
>>> Date: Fri, 27 May 2011 13:47:54 +
>>> Subject: Re: Active slice, only for a next boot
>>>
 On Fri May 27 11, rank1see...@gmail.com 
 wrote:

>
> Idea is ...
> I have i.e; 3 slices, of which first is active.
> Now I wana set slice 2 active, but only for a one/next boot.
> Once slice 2 is booted and system is shutdown or rebooted, 
once again,

>>>
>>> first slice is active and booted, without user's intervention.
>
> Is this possible or should be implemented?
>
>
> nextboot(8) USED to do this before it was broken by someone to 
"look into the filesystem"
> for it's next boot hint which is obviously broken if you are 
trying to get to another filesystem

> because the main one is broken.
>

Doesn't sound that useful to me- I think of the main use for 
nextboot being to try new kernels on a one-time basis. If you're 
rescuing a broken filesystem surely it's better to just set another 
slice active?




try using it on an appliance

it has to recover  on its own from a complete filesystem screwup. 

i.e.  a 100% recovery with NO HUMAN INTERVENTION.
even in the case of a dead/dieing drive. (requires that bios has drive 
boot order feature)


I will add that this functionality is so useful that several companies 
still maintain the old bootblocks internally

(e.g. cisco)

The new functionality was introduced without an consultation and the 
old functionality just 'lost'.

Which was just bad design and project management..





Chris



___
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"




___
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: Active slice, only for a next boot

[Julian Elischer]

On 5/28/11 4:06 AM, Chris Rees wrote:



On 28 May 2011 10:04, "Julian Elischer" > wrote:

>
> On 5/27/11 11:34 AM, Warner Losh wrote:
>>
>> On May 27, 2011, at 10:47 AM, rank1see...@gmail.com 
 wrote:

>>
>>> - Original Message -
>>> From: Alexander Best>

>>> To: rank1see...@gmail.com 
>>> Cc: hack...@freebsd.org 
>>> Date: Fri, 27 May 2011 13:47:54 +
>>> Subject: Re: Active slice, only for a next boot
>>>
 On Fri May 27 11, rank1see...@gmail.com 
 wrote:

>
> Idea is ...
> I have i.e; 3 slices, of which first is active.
> Now I wana set slice 2 active, but only for a one/next boot.
> Once slice 2 is booted and system is shutdown or rebooted, 
once again,

>>>
>>> first slice is active and booted, without user's intervention.
>
> Is this possible or should be implemented?
>
>
> nextboot(8) USED to do this before it was broken by someone to 
"look into the filesystem"
> for it's next boot hint which is obviously broken if you are 
trying to get to another filesystem

> because the main one is broken.
>

Doesn't sound that useful to me- I think of the main use for 
nextboot being to try new kernels on a one-time basis. If you're 
rescuing a broken filesystem surely it's better to just set another 
slice active?




try using it on an appliance

it has to recover on its own from a complete filesystem screwup.


Chris



___
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: Active slice, only for a next boot

[Julian Elischer]

On 5/28/11 6:06 AM, rank1see...@gmail.com wrote:

And how about this:

# boot0cfg -o noupdate -s 1
Now when you choose to hit slice 2, it is only for a this one boot.
Next and each boot, defaults to slice 1

Problem is, that you must see, early bootstrap, to manually choose, so this 
won't work on a remote server.
This requires:
a) physicall access
or
b) ssh access to the remote box, which is conected via serial cable, to your 
server.

Anyone has any idea, for a case of a remote server, which is accessible over ssh, only 
when it is "up"?


pull the old bootblocks from about 2000 and use them.
and nextboot as well
they do exactly what you want.

OR

ask Doug Ambrisko (cc'd) for a copy of them that he still uses at work.
He may have updates to make them work with modern systems that would 
save you time.


the old nextboot(8) stored instructions as to what to do on block 1 of 
the drive
 (you can make it a small 1 block partition if you want). Actually it 
stored a series of them, NULL separated.
On each boot the boot 0 bloter would read the first (after skipping 
any nulls) and then write Nulls over

what it just read and write it back to block 1.
so it would progress gradualy boot by boot over the sequence written 
by nextboot.


it would pass on the stack, what it had read to boot1.


the format was "hd(1,a)/boot/loader"(for example)
personally I would like to hav ethis capabiltiy back because it's 
stupid  rely on a
possibly dead filesystem to get around booting from the possibly dead 
filesystem.


by default we used to have a /etc/rc entry that would rewrite the 
'current' setup several times on successful boot,

followed by a couple of alternate boot targets.
If boot failed a coupke of times it would automatically boot from the 
second drive or from another partition,

..






Domagoj Smolčić
___
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"




___
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: [rfc] a few kern.mk and bsd.sys.mk related changes

[Pan Tsu]

Alexander Best  writes:

> On Fri May 27 11, Alexander Best wrote:
>> On Fri May 27 11, Warner Losh wrote:
>> > These look generally good.  Just one thing I had a question on:
>> > 
>> >  #
>> > +# Enable FreeBSD kernel-specific printf format specifiers. Also instruct 
>> > gcc to
>> > +# enable some diagnostics, which make it easier to pinpoint tinderbox 
>> > failures.
>> > +CFLAGS+=  -fformat-extensions -fdiagnostics-show-option
>> > +
>> > 
>> > Does this put sand in the gears of clang support?
>
> i've improved the above comment so as to note that clang won't be affected by
> -fdiagnostics-show-option. the new patch is available here:
>
> http://people.freebsd.org/~arundel/patches/kern.mk-bsy.sys.mk.patch
>
> another "issue" i've come across is the fact that on amd64, -O2 is always 
> being
> set, no matter, if debugging is enabled or disabled. i think amd64 should also
> (just like all the other archs) be using -O, when debugging was enabled.

Any reason a kernel with symbols (DEBUG) *must* be pessimized to -O1 level?
Looking at r140606 it's not clear how symbols are related to a bump
from -O1 to -O2 for non-amd64 archs. And -RELEASE kernels since at least
6.0R have `makeoptions DEBUG=-g' uncommented in GENERIC.

> changing this is quite easy. so if people think this is something worth
> changing i can integrate it into my existing patch.
___
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: Active slice, only for a next boot

[rank1seeker]

And how about this:

# boot0cfg -o noupdate -s 1
Now when you choose to hit slice 2, it is only for a this one boot.
Next and each boot, defaults to slice 1

Problem is, that you must see, early bootstrap, to manually choose, so this 
won't work on a remote server.
This requires:
a) physicall access 
   or
b) ssh access to the remote box, which is conected via serial cable, to your 
server.

Anyone has any idea, for a case of a remote server, which is accessible over 
ssh, only when it is "up"?


Domagoj Smolčić
___
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: Active slice, only for a next boot

[Chris Rees]

On 28 May 2011 10:04, "Julian Elischer"  wrote:
>
> On 5/27/11 11:34 AM, Warner Losh wrote:
>>
>> On May 27, 2011, at 10:47 AM, rank1see...@gmail.com wrote:
>>
>>> - Original Message -
>>> From: Alexander Best
>>> To: rank1see...@gmail.com
>>> Cc: hack...@freebsd.org
>>> Date: Fri, 27 May 2011 13:47:54 +
>>> Subject: Re: Active slice, only for a next boot
>>>
 On Fri May 27 11, rank1see...@gmail.com wrote:
>
> Idea is ...
> I have i.e; 3 slices, of which first is active.
> Now I wana set slice 2 active, but only for a one/next boot.
> Once slice 2 is booted and system is shutdown or rebooted, once again,
>>>
>>> first slice is active and booted, without user's intervention.
>
> Is this possible or should be implemented?
>
>
> nextboot(8) USED to do this before it was broken by someone to "look into
the filesystem"
> for it's next boot hint which is obviously broken if you are trying to get
to another filesystem
> because the main one is broken.
>

Doesn't sound that useful to me- I think of the main use for nextboot being
to try new kernels on a one-time basis. If you're rescuing a broken
filesystem surely it's better to just set another slice active?

Chris
___
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: [rfc] a few kern.mk and bsd.sys.mk related changes

[Alexander Best]

On Fri May 27 11, Warner Losh wrote:
> 
> On May 27, 2011, at 12:14 PM, Alexander Best wrote:
> 
> > On Fri May 27 11, Warner Losh wrote:
> >> These look generally good.  Just one thing I had a question on:
> >> 
> >> #
> >> +# Enable FreeBSD kernel-specific printf format specifiers. Also instruct 
> >> gcc to
> >> +# enable some diagnostics, which make it easier to pinpoint tinderbox 
> >> failures.
> >> +CFLAGS+=  -fformat-extensions -fdiagnostics-show-option
> >> +
> >> 
> >> Does this put sand in the gears of clang support?
> > 
> > i don't think so. the code that features -fformat-extensions support is 
> > freebsd
> > specific and gets plugged into the vendor code during every new import. dim@
> > and rdivacky@ have been discussing the possibility of getting this committed
> > upstream as something like -ffreebsd-extensions, but they haven't decided, 
> > yet.
> 
> OK.  I have a bunch of uncommitted changes to support external toolchains, 
> and this sort of thing might bite me when them...  But I'll fight with that 
> when I get there.

well the main problem imho is -fformat-extensions. the code that supports this
flag has not been pushed upstream neither to clang, nor to gcc. so compiling
the freebsd kernel with anything external, like clang tot or gcc 4.6 will fail
to recognise the special printf formatting.

personally i think getting this committed upsteam to clang as
-ffreebsd-extensions would be a nice thing to have. however it's not my
decision to make. ;)

the -fdiagnostics-show-option flag is a standard clang and gcc flag and won't
cause any problems. the only difference between gcc and clang is: gcc has it
disabled by default; clang has it enabled by default.

i've reworked my patch yet again. it now features these changes:

1) -W is now called -Wextra
2) move -fformat-extensions and -fdiagnostics-show-option out of CWARNFLAGS,
   since they aren't really warnings. this will now let anybody use custom
   CWARNFLAGS without having to remember to add -fformat-extensions in order
   not to break buildworld.
3) rearrange "\" characters, as to avoid double spaces
4) when building kernel modules, -fstack-protector was added to CFLAGS twice.
   this should now be solved.
5) only enable -frename-registers, when gcc is used, since clang doesn't
   understand this flag
6) when debugging is enabled, also use the -O flag for amd64 and not -O2. when
   people enable debugging they don't really want optimisations such as -O2
   turned on.

the patch is available here:

http://people.freebsd.org/~arundel/patches/kern.mk-bsd.sys.mk.patch

NB:
regarding point 2), i'd like to encurrage people to play around with CWARNFLAGS
a bit. maybe we find some nice -Wwarning options which are reasonable to have
and - most importantly - don't break tinderbox. for far i've played around with
the following flags and can verify that they break tinderbox:

-Wshadow, -Wwrite-strings, -Wextra, -Wbad-function-cast and
-Wmissing-declarations

-Wmissing-declarations almost works, but there are ~ 20 undeclared functions in
the dtrace code. if those could be fixed it would be possible to add that flag
to CWARNFLAGS.

cheers.
alex

> 
> > regarding -fdiagnostics-show-option: this is intended purely for gcc, since 
> > it
> > is disabled per default. under clang the flag exists, too, but it is 
> > enabled by
> > default. so specifying it under clang is pretty much a nop.
> 
> Cool.  This is less of a concern, since it will be present in most external 
> toolchains I care about.
> 
> Warner
> 
> > cheers.
> > alex
> > 
> >> 
> >> Warner
> >> 
> >> 
> >> On May 27, 2011, at 5:51 AM, Alexander Best wrote:
> >> 
> >>> hi there,
> >>> 
> >>> i would like to hear people's opinion regarding the following patch. it
> >>> features the following semantic changes:
> >>> 
> >>> 1) -W is now called -Wextra
> >>> 2) move -fformat-extensions and -fdiagnostics-show-option out of 
> >>> CWARNFLAGS,
> >>>  since they aren't really warnings. this will now let anybody use custom
> >>>  CWARNFLAGS without having to remember to add -fformat-extensions in order
> >>>  not to break buildworld.
> >>> 3) rearrange "\" characters, as to avoid double spaces
> >>> 4) when building kernel modules, -fstack-protector was added to CFLAGS 
> >>> twice.
> >>>  this should now be solved.
> >>> 
> >>> cheers.
> >>> alex
> >>> 
> >>> -- 
> >>> a13x
> >>> ___
> >>> freebsd-toolch...@freebsd.org mailing list
> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> >>> To unsubscribe, send any mail to 
> >>> "freebsd-toolchain-unsubscr...@freebsd.org"
> > 
> > -- 
> > a13x
> > 
> > 

-- 
a13x
___
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: Active slice, only for a next boot

[Julian Elischer]

On 5/27/11 11:34 AM, Warner Losh wrote:

On May 27, 2011, at 10:47 AM, rank1see...@gmail.com wrote:


- Original Message -
From: Alexander Best
To: rank1see...@gmail.com
Cc: hack...@freebsd.org
Date: Fri, 27 May 2011 13:47:54 +
Subject: Re: Active slice, only for a next boot


On Fri May 27 11, rank1see...@gmail.com wrote:

Idea is ...
I have i.e; 3 slices, of which first is active.
Now I wana set slice 2 active, but only for a one/next boot.
Once slice 2 is booted and system is shutdown or rebooted, once again,

first slice is active and booted, without user's intervention.

Is this possible or should be implemented?


nextboot(8) USED to do this before it was broken by someone to "look 
into the filesystem"
for it's next boot hint which is obviously broken if you are trying to 
get to another filesystem

because the main one is broken.


take a look at the gpart(8) manual, expecially the ATTRIBUTES section. if

you

are running with a GPT scheme you can use the "bootonce" attribute to do
exactly what you asked for.

cheers.
alex


Thanls, but I need it for MBR.

gpart works with MBR.

Warner

___
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"



___
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"