Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Sun, Aug 14, 2011 at 11:35 AM, Garrett Cooper wrote:
> On Sun, Aug 14, 2011 at 10:56 AM, Freddie Cash wrote:
> > On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best >wrote:
> >
> >> hi there,
> >>
> >> i just had the following idea: how about instead of copying the current
> >> kernel
> >> to /boot/kernel.old and then installing the new one under /boot/kernel
> as
> >> the
> >> results of target installkernel, we create a unique directory name for
> the
> >> old
> >> kernel?
> >>
> >> something like /boot/kernel-r${revision}-${/dev/random}?
> >>
> >> that would let people not only boot the previous kernel, but all kernels
> >> that
> >> have been replaced by target installkernel. this would make tracking
> >> issues,
> >> which have been introduced by a certain commit much easier, imho.
> >>
> >> i don't think implementing this logic would be that difficult. the only
> >> problem
> >> i see is with ${/dev/random} in the case where people are running a
> kernel
> >> without /dev/{u}random support.
> >>
> >
> > A better method may be to use KODIR to install the *new* kernel to a
> unique
> > directory via installkernel (make KERNCONF=SOMEKERNEL
> > KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using
> "nextboot
> > -k SOMEKERNEL-rev-whatever" to set that kernel as bootable on the next
> boot.
> >
> > You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and
> > then make that the default kernel (rm -rf /boot/kernel; cp -Rvp
> > /boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now).
> >
> > Sure, it's not automated yet, but the building blocks are there.
> >
> > This way, you never disturb the currently working kernel until you know
> the
> > new kernel works. And if things go south with the new kernel, a simple
> > reboot is all that's needed to revert back to the working /boot/kernel.
> >
> > All that's needed is to automate things a bit (pick KODIR, set nextboot,
> > create a post-install target of some kind to run after booting the new
> > kernel).
> >
> > And, this leaves all of your kernels around if you want to play with
> > different ones.
>
>Again, why build more complexity into the system when it does what
> you want in a more generic manner? Just to illustrate what I do on a
> weekly basis, here's my script and example invocation (I have other
> instances where I have more KERNCONFs and things are more
> complicated). You shouldn't have to do much more than what I did below
> when dealing with your specific case of interest -- especially
> because, as you and others have identified elsewhere it may not work,
> it might fill up whatever partition /boot is on, etc.
>
Unless I'mmissing something, we're saying essentially the same thing
(install new kernel to unique directory) , but you've done the work to
actually automate it. :)
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On 8/14/11 3:27 AM, Eduardo Morras wrote: At 22:06 13/08/2011, Steven Hartland wrote: - Original Message - From: "Alexander Best" i just had the following idea: how about instead of copying the current kernel to /boot/kernel.old and then installing the new one under /boot/kernel as the results of target installkernel, we create a unique directory name for the old kernel? The default size of / is likely your biggest problem. Don't know how much compresable is /boot/kernel.old but tar with -z or -j may be a workaround. We can extract on demand and swap current /boot/kernel with new /boot/kernel. Other way of do it is link /boot/kernel to current kernel and update it, but i don't know (again) if it would work in single user mode. What would make more sense to me for thsi would be a kernel name that was recognised by teh final boot stages as being an exeprimental kernel and moved to the new location only on successful boot.. Once you have successfully booted it, then you delete the kernel[-1] and do the replacement that "make installkernel" now does. Regards Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
Freddie Cash writes:
> On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best wrote:
>
>> hi there,
>>
>> i just had the following idea: how about instead of copying the current
>> kernel
>> to /boot/kernel.old and then installing the new one under /boot/kernel as
>> the
>> results of target installkernel, we create a unique directory name for the
>> old
>> kernel?
>>
>> something like /boot/kernel-r${revision}-${/dev/random}?
>>
>> that would let people not only boot the previous kernel, but all kernels
>> that
>> have been replaced by target installkernel. this would make tracking
>> issues,
>> which have been introduced by a certain commit much easier, imho.
>>
>> i don't think implementing this logic would be that difficult. the only
>> problem
>> i see is with ${/dev/random} in the case where people are running a kernel
>> without /dev/{u}random support.
>>
>
> A better method may be to use KODIR to install the *new* kernel to a unique
> directory via installkernel (make KERNCONF=SOMEKERNEL
> KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using "nextboot
> -k SOMEKERNEL-rev-whatever" to set that kernel as bootable on the next boot.
>
> You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and
> then make that the default kernel (rm -rf /boot/kernel; cp -Rvp
> /boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now).
[...]
nextboot needs write access in loader to reset kernel, which is only
available for ufs. So, forget about zfs and every other fs from
libstand(3), e.g. ext2fs, msdosfs, nfs.
bootonce is also only supported in gptboot (ufs), not gptzfsboot.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Sun, Aug 14, 2011 at 10:56 AM, Freddie Cash wrote:
> On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best wrote:
>
>> hi there,
>>
>> i just had the following idea: how about instead of copying the current
>> kernel
>> to /boot/kernel.old and then installing the new one under /boot/kernel as
>> the
>> results of target installkernel, we create a unique directory name for the
>> old
>> kernel?
>>
>> something like /boot/kernel-r${revision}-${/dev/random}?
>>
>> that would let people not only boot the previous kernel, but all kernels
>> that
>> have been replaced by target installkernel. this would make tracking
>> issues,
>> which have been introduced by a certain commit much easier, imho.
>>
>> i don't think implementing this logic would be that difficult. the only
>> problem
>> i see is with ${/dev/random} in the case where people are running a kernel
>> without /dev/{u}random support.
>>
>
> A better method may be to use KODIR to install the *new* kernel to a unique
> directory via installkernel (make KERNCONF=SOMEKERNEL
> KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using "nextboot
> -k SOMEKERNEL-rev-whatever" to set that kernel as bootable on the next boot.
>
> You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and
> then make that the default kernel (rm -rf /boot/kernel; cp -Rvp
> /boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now).
>
> Sure, it's not automated yet, but the building blocks are there.
>
> This way, you never disturb the currently working kernel until you know the
> new kernel works. And if things go south with the new kernel, a simple
> reboot is all that's needed to revert back to the working /boot/kernel.
>
> All that's needed is to automate things a bit (pick KODIR, set nextboot,
> create a post-install target of some kind to run after booting the new
> kernel).
>
> And, this leaves all of your kernels around if you want to play with
> different ones.
Again, why build more complexity into the system when it does what
you want in a more generic manner? Just to illustrate what I do on a
weekly basis, here's my script and example invocation (I have other
instances where I have more KERNCONFs and things are more
complicated). You shouldn't have to do much more than what I did below
when dealing with your specific case of interest -- especially
because, as you and others have identified elsewhere it may not work,
it might fill up whatever partition /boot is on, etc.
Thanks,
-Garrett
$ cat ~root/bin/installkernel
#!/bin/sh
SRCCONF=${SRCCONF:=/etc/src.conf}
set -e
for i in $(make -f "$SRCCONF" -V KERNCONF); do
# Using svn info is bad because that captures the sourcebase revision,
# which may or may not match the actual kernel being installed's revision.
# Something like `strings kernel | awk '/^FreeBSD [0-9]+/' ' would be
# better.
sudo make installkernel \
KERNCONF=$i \
INSTKERNNAME=$i.r$(svn info | awk '/^Revision/ {print
$2}')${SUFFIX:+.$SUFFIX} \
$*
done
Example:
$ make -VKERNCONF -f /etc/src.conf
BAYONETTA
$ cd /usr/src && ~root/bin/installkernel && ln -sfh BAYONETTA
/boot/kernel && reboot
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best wrote:
> hi there,
>
> i just had the following idea: how about instead of copying the current
> kernel
> to /boot/kernel.old and then installing the new one under /boot/kernel as
> the
> results of target installkernel, we create a unique directory name for the
> old
> kernel?
>
> something like /boot/kernel-r${revision}-${/dev/random}?
>
> that would let people not only boot the previous kernel, but all kernels
> that
> have been replaced by target installkernel. this would make tracking
> issues,
> which have been introduced by a certain commit much easier, imho.
>
> i don't think implementing this logic would be that difficult. the only
> problem
> i see is with ${/dev/random} in the case where people are running a kernel
> without /dev/{u}random support.
>
A better method may be to use KODIR to install the *new* kernel to a unique
directory via installkernel (make KERNCONF=SOMEKERNEL
KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using "nextboot
-k SOMEKERNEL-rev-whatever" to set that kernel as bootable on the next boot.
You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and
then make that the default kernel (rm -rf /boot/kernel; cp -Rvp
/boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now).
Sure, it's not automated yet, but the building blocks are there.
This way, you never disturb the currently working kernel until you know the
new kernel works. And if things go south with the new kernel, a simple
reboot is all that's needed to revert back to the working /boot/kernel.
All that's needed is to automate things a bit (pick KODIR, set nextboot,
create a post-install target of some kind to run after booting the new
kernel).
And, this leaves all of your kernels around if you want to play with
different ones.
> cheers.
> alex
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Sun Aug 14 11, Test Rat wrote: > Test Rat writes: > > > Eduardo Morras writes: > > > >> At 22:06 13/08/2011, Steven Hartland wrote: > >>>> i just had the following idea: how about instead of copying the > >>>> current kernel > >>>>to /boot/kernel.old and then installing the new one under /boot/kernel as > >>>>the > >>>> results of target installkernel, we create a unique directory name > >>>> for the old > >>>>kernel? > >>> > >>>The default size of / is likely your biggest problem. > >> > >> Don't know how much compresable is /boot/kernel.old but tar with -z > >> or -j may be a workaround. We can extract on demand and swap current > >> /boot/kernel with new /boot/kernel. Other way of do it is link > >> /boot/kernel to current kernel and update it, but i don't know > >> (again) if it would work in single user mode. > > > > There is kgzldr that lets you boot compressed kernels. Try > > > > $ gzip /boot/kernel/* > > $ reboot the above works for me. just booted a compressed kernel. > > Nevermind, I've confused it with gzip support in loader, it also > has bzip2 support which for some reason doesn't work for me > > bzf_read: BZ2_bzDecompress returned -3 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
Test Rat writes: > Eduardo Morras writes: > >> At 22:06 13/08/2011, Steven Hartland wrote: >>>> i just had the following idea: how about instead of copying the >>>> current kernel >>>>to /boot/kernel.old and then installing the new one under /boot/kernel as >>>>the >>>> results of target installkernel, we create a unique directory name >>>> for the old >>>>kernel? >>> >>>The default size of / is likely your biggest problem. >> >> Don't know how much compresable is /boot/kernel.old but tar with -z >> or -j may be a workaround. We can extract on demand and swap current >> /boot/kernel with new /boot/kernel. Other way of do it is link >> /boot/kernel to current kernel and update it, but i don't know >> (again) if it would work in single user mode. > > There is kgzldr that lets you boot compressed kernels. Try > > $ gzip /boot/kernel/* > $ reboot Nevermind, I've confused it with gzip support in loader, it also has bzip2 support which for some reason doesn't work for me bzf_read: BZ2_bzDecompress returned -3 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
Eduardo Morras writes: > At 22:06 13/08/2011, Steven Hartland wrote: >>> i just had the following idea: how about instead of copying the >>> current kernel >>>to /boot/kernel.old and then installing the new one under /boot/kernel as the >>> results of target installkernel, we create a unique directory name >>> for the old >>>kernel? >> >>The default size of / is likely your biggest problem. > > Don't know how much compresable is /boot/kernel.old but tar with -z > or -j may be a workaround. We can extract on demand and swap current > /boot/kernel with new /boot/kernel. Other way of do it is link > /boot/kernel to current kernel and update it, but i don't know > (again) if it would work in single user mode. There is kgzldr that lets you boot compressed kernels. Try $ gzip /boot/kernel/* $ reboot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
At 22:06 13/08/2011, Steven Hartland wrote: - Original Message - From: "Alexander Best" i just had the following idea: how about instead of copying the current kernel to /boot/kernel.old and then installing the new one under /boot/kernel as the results of target installkernel, we create a unique directory name for the old kernel? The default size of / is likely your biggest problem. Don't know how much compresable is /boot/kernel.old but tar with -z or -j may be a workaround. We can extract on demand and swap current /boot/kernel with new /boot/kernel. Other way of do it is link /boot/kernel to current kernel and update it, but i don't know (again) if it would work in single user mode. Regards Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Aug 13, 2011, at 1:15 PM, Alexander Best wrote:
> On Sat Aug 13 11, Garrett Cooper wrote:
>> On Aug 13, 2011, at 12:51 PM, Alexander Best wrote:
>>
>>> hi there,
>>>
>>> i just had the following idea: how about instead of copying the current
>>> kernel
>>> to /boot/kernel.old and then installing the new one under /boot/kernel as
>>> the
>>> results of target installkernel, we create a unique directory name for the
>>> old
>>> kernel?
>>>
>>> something like /boot/kernel-r${revision}-${/dev/random}?
>>>
>>> that would let people not only boot the previous kernel, but all kernels
>>> that
>>> have been replaced by target installkernel. this would make tracking issues,
>>> which have been introduced by a certain commit much easier, imho.
>>>
>>> i don't think implementing this logic would be that difficult. the only
>>> problem
>>> i see is with ${/dev/random} in the case where people are running a kernel
>>> without /dev/{u}random support.
>>
>> Why not just use INSTKERNNAME?
>
> hmm...won't setting INSTKERNNAME set the path to where the new kernel will be
> installed and not where the current kernel will be backup'ed?
It moves the old kernel to $INSTKERNNAME.old . That's usually good enough when
working with svn and multiple KERNCONFs.
-Garrett___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
- Original Message - From: "Alexander Best" i just had the following idea: how about instead of copying the current kernel to /boot/kernel.old and then installing the new one under /boot/kernel as the results of target installkernel, we create a unique directory name for the old kernel? The default size of / is likely your biggest problem. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Sat Aug 13 11, Garrett Cooper wrote:
> On Aug 13, 2011, at 12:51 PM, Alexander Best wrote:
>
> > hi there,
> >
> > i just had the following idea: how about instead of copying the current
> > kernel
> > to /boot/kernel.old and then installing the new one under /boot/kernel as
> > the
> > results of target installkernel, we create a unique directory name for the
> > old
> > kernel?
> >
> > something like /boot/kernel-r${revision}-${/dev/random}?
> >
> > that would let people not only boot the previous kernel, but all kernels
> > that
> > have been replaced by target installkernel. this would make tracking issues,
> > which have been introduced by a certain commit much easier, imho.
> >
> > i don't think implementing this logic would be that difficult. the only
> > problem
> > i see is with ${/dev/random} in the case where people are running a kernel
> > without /dev/{u}random support.
>
> Why not just use INSTKERNNAME?
hmm...won't setting INSTKERNNAME set the path to where the new kernel will be
installed and not where the current kernel will be backup'ed?
> -Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Aug 13, 2011, at 12:51 PM, Alexander Best wrote:
> hi there,
>
> i just had the following idea: how about instead of copying the current kernel
> to /boot/kernel.old and then installing the new one under /boot/kernel as the
> results of target installkernel, we create a unique directory name for the old
> kernel?
>
> something like /boot/kernel-r${revision}-${/dev/random}?
>
> that would let people not only boot the previous kernel, but all kernels that
> have been replaced by target installkernel. this would make tracking issues,
> which have been introduced by a certain commit much easier, imho.
>
> i don't think implementing this logic would be that difficult. the only
> problem
> i see is with ${/dev/random} in the case where people are running a kernel
> without /dev/{u}random support.
Why not just use INSTKERNNAME?
-Garrett___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Sat Aug 13 11, Chris Rees wrote:
> On 13 August 2011 20:51, Alexander Best wrote:
> > hi there,
> >
> > i just had the following idea: how about instead of copying the current
> > kernel
> > to /boot/kernel.old and then installing the new one under /boot/kernel as
> > the
> > results of target installkernel, we create a unique directory name for the
> > old
> > kernel?
> >
> > something like /boot/kernel-r${revision}-${/dev/random}?
> >
> > that would let people not only boot the previous kernel, but all kernels
> > that
> > have been replaced by target installkernel. this would make tracking issues,
> > which have been introduced by a certain commit much easier, imho.
> >
> > i don't think implementing this logic would be that difficult. the only
> > problem
> > i see is with ${/dev/random} in the case where people are running a kernel
> > without /dev/{u}random support.
> >
> > cheers.
> > alex
>
> mktemp?
ahh. nice. unless mktemp(1) relies on "device random", that sounds like a good
solution. :)
>
> Chris
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On 13 August 2011 20:51, Alexander Best wrote:
> hi there,
>
> i just had the following idea: how about instead of copying the current kernel
> to /boot/kernel.old and then installing the new one under /boot/kernel as the
> results of target installkernel, we create a unique directory name for the old
> kernel?
>
> something like /boot/kernel-r${revision}-${/dev/random}?
>
> that would let people not only boot the previous kernel, but all kernels that
> have been replaced by target installkernel. this would make tracking issues,
> which have been introduced by a certain commit much easier, imho.
>
> i don't think implementing this logic would be that difficult. the only
> problem
> i see is with ${/dev/random} in the case where people are running a kernel
> without /dev/{u}random support.
>
> cheers.
> alex
mktemp?
Chris
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[rfc] replacing /boot/kernel.old with a unique directory name
hi there,
i just had the following idea: how about instead of copying the current kernel
to /boot/kernel.old and then installing the new one under /boot/kernel as the
results of target installkernel, we create a unique directory name for the old
kernel?
something like /boot/kernel-r${revision}-${/dev/random}?
that would let people not only boot the previous kernel, but all kernels that
have been replaced by target installkernel. this would make tracking issues,
which have been introduced by a certain commit much easier, imho.
i don't think implementing this logic would be that difficult. the only problem
i see is with ${/dev/random} in the case where people are running a kernel
without /dev/{u}random support.
cheers.
alex
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kernel.old
As Chuck Robey wrote ... > I was thinking about Peter Wemm's recent change to the kernel Makefile, > making a way to install multiple kernels without fragging your last > known good kernel, and it got me to thinking, scragging kernel.old, now > that we have good kld's, isn't the only way to find yourself well and > truly screwed if your new kernel decides it's shy. Shy enough to hide on the swap device after a panic ;-) ? Groeten / Cheers, | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel.old
I wish :-( It seems that some people think that it is OK to make changes to stable even though those changes break things which used to work. IMHO, branches of the kernel SHOULD be like shared libraries. (It is OK to ADD previously absent features or CORRECT internal errors, but NOT OK to delete features or change API's) On Sun, 9 May 1999, Poul-Henning Kamp wrote: > I think you are seeing -current as the norm. You shouldn't. Under > -stable the modules should (tm) continue to work since there are not > made API changes in -stable. Personally, I think that we should treat kernels just like another library. They export an API (sysctl) that libc, et. al. uses and another API that the kernel modules use. Any change that "breaks" code which is compliant with those API's belongs in a new release branch. PERIOD. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel.old
> >Something on the order of modules.old is going to need to > >be implemented. > > Not to mention /boot/kernel.old.config ... > > I think you are seeing -current as the norm. You shouldn't. Under > -stable the modules should (tm) continue to work since there are not > made API changes in -stable. BUT we shouldn't make it easy for our developers (who do need to run -CURRENT) to kill themselves. Our development time is limited, and recovering from a bum kernel can be a PITA in some situations, so lets not waste our development time when we don't need to. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel.old
In message , Chuck Robe y writes: >Something on the order of modules.old is going to need to >be implemented. Not to mention /boot/kernel.old.config ... I think you are seeing -current as the norm. You shouldn't. Under -stable the modules should (tm) continue to work since there are not made API changes in -stable. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
kernel.old
I was thinking about Peter Wemm's recent change to the kernel Makefile, making a way to install multiple kernels without fragging your last known good kernel, and it got me to thinking, scragging kernel.old, now that we have good kld's, isn't the only way to find yourself well and truly screwed if your new kernel decides it's shy. If your new /modules directory has some incompatibilities with your old kernel, well, you aren't going to be able to save yourself by booting kernel.old. Something on the order of modules.old is going to need to be implemented. Seeing as the modules build isn't in the same part of the (logical) world as the kernel, well, this is somewhat more complicated than it would otherwise be. Is there any chance of the installation of modules being made the responsibility of the kernel Makefile, and not src/modules/Makefile.* ? If that were true, then the kernel installation could be tied to modules installation, and the rotation of the kernel could be extended to rotation of the modules directory. Ideally, I'd want the entire build of modules to be in that Makefile, but I guess that's dreaming. Think about it, it makes some sense, tho, doesn't it? +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
