On 12/23/2011 01:14, Bjoern A. Zeeb wrote:
>
> On 23. Dec 2011, at 01:40 , Doug Barton wrote:
>
>> On 12/21/2011 23:20, Gleb Smirnoff wrote:
>>> On Wed, Dec 21, 2011 at 12:35:23PM -0800, Doug Barton wrote:
>>>
>>> D> So does that mean that if I upgrade to the latest HEAD from a system
>>> D> buil
On 23. Dec 2011, at 01:40 , Doug Barton wrote:
> On 12/21/2011 23:20, Gleb Smirnoff wrote:
>> On Wed, Dec 21, 2011 at 12:35:23PM -0800, Doug Barton wrote:
>>
>> D> So does that mean that if I upgrade to the latest HEAD from a system
>> D> built before the ifconfig changes that when I reboot my n
On 12/22/2011 23:22, Gleb Smirnoff wrote:
> On Thu, Dec 22, 2011 at 05:40:03PM -0800, Doug Barton wrote:
> D> > D> So does that mean that if I upgrade to the latest HEAD from a system
> D> > D> built before the ifconfig changes that when I reboot my network will
> D> > D> come up?
> D> >
> D> > Ye
On Thu, Dec 22, 2011 at 05:40:03PM -0800, Doug Barton wrote:
D> > D> So does that mean that if I upgrade to the latest HEAD from a system
D> > D> built before the ifconfig changes that when I reboot my network will
D> > D> come up?
D> >
D> > Yes, older infconfig will work in "head < r228571 || hea
On 12/21/2011 23:20, Gleb Smirnoff wrote:
> On Wed, Dec 21, 2011 at 12:35:23PM -0800, Doug Barton wrote:
>
> D> So does that mean that if I upgrade to the latest HEAD from a system
> D> built before the ifconfig changes that when I reboot my network will
> D> come up?
>
> Yes, older infconfig will
On 12/21/2011 23:20, Gleb Smirnoff wrote:
> I'm afraid, if we would try to document every kernel<->userland API/ABI
> change in head/ in the UPDATING, then the file will grow extremely quickly,
> and still many issues will be forgotten to be added there.
That doesn't mean we shouldn't do our best
On Wed, Dec 21, 2011 at 12:35:23PM -0800, Doug Barton wrote:
D> > On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote:
D> > B> While this is the documented path, it's not actually been required
D> > B> except in edge cases for ages (the last I can remember is a.out->elf).
D> > B> It's been
On Tue, Dec 20, 2011 at 11:23:54PM +0400, Gleb Smirnoff wrote:
> Considering r228571: we need to specify vhid as additional address
> attribute in atomic manner, via one ioctl(). Address can't be first
> configured, and then made redundant, that would lead it to being
> static for a short period, s
On 12/21/2011 4:55 AM, Gleb Smirnoff wrote:
> Brooks,
>
> On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote:
> B> While this is the documented path, it's not actually been required
> B> except in edge cases for ages (the last I can remember is a.out->elf).
> B> It's been long enough t
On Wed, Dec 21, 2011 at 04:55:40PM +0400, Gleb Smirnoff wrote:
> Brooks,
>
> On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote:
> B> While this is the documented path, it's not actually been required
> B> except in edge cases for ages (the last I can remember is a.out->elf).
> B> It's
Brooks,
On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote:
B> While this is the documented path, it's not actually been required
B> except in edge cases for ages (the last I can remember is a.out->elf).
B> It's been long enough that I don't think we can really make people do
B> it exc
On Tue, Dec 20, 2011 at 11:23:54PM +0400, Gleb Smirnoff wrote:
> Brooks,
>
> On Tue, Dec 20, 2011 at 10:51:34AM -0600, Brooks Davis wrote:
> B> We almost certainly need to back r228571 out. This is not an acceptable
> B> upgrade path that would be acceptable historically. Specially, we have
>
On Tue, Dec 20, 2011 at 11:15:20PM +0400, Gleb Smirnoff wrote:
> Doug,
>
> On Tue, Dec 20, 2011 at 12:38:53AM -0800, Doug Barton wrote:
> D> > I saw this too, when my kernel and userland were out of sync (e.g. just
> D> > after installing a new kernel, and before installworld). I suspect it
> D
On 20. Dec 2011, at 19:35 , Gleb Smirnoff wrote:
> On Tue, Dec 20, 2011 at 01:30:34PM -0600, Brooks Davis wrote:
> B> I also worry about the problem that once you've installed world there is
> B> no easy way back.
>
> When working on the patch for last months I did numerous 'make installkernel
>
On Tue, Dec 20, 2011 at 01:30:34PM -0600, Brooks Davis wrote:
B> I also worry about the problem that once you've installed world there is
B> no easy way back.
When working on the patch for last months I did numerous 'make installkernel
installworld' switching between a patched sources and unpatche
On Tue, Dec 20, 2011 at 06:48:40PM +, Bjoern A. Zeeb wrote:
> On 20. Dec 2011, at 16:51 , Brooks Davis wrote:
>
> > On Tue, Dec 20, 2011 at 04:43:21PM +0100, Dimitry Andric wrote:
> >> On 2011-12-20 09:38, Doug Barton wrote:
> >> ...
> >>> I tried replacing both ifconfig and dhclient with the
T> An assumption that we are not allowed to change ABI for our own tools
T> strongly discourages bringing in new features :(
P.S. Quoting documentation: "The old world might not run correctly on the new
kernel, so you must install the new world immediately upon installing the new
kernel."
http:
Brooks,
On Tue, Dec 20, 2011 at 10:51:34AM -0600, Brooks Davis wrote:
B> We almost certainly need to back r228571 out. This is not an acceptable
B> upgrade path that would be acceptable historically. Specially, we have
B> effectively promised users that an X.Y world will work on an X+1.0
B> ke
Doug,
On Tue, Dec 20, 2011 at 12:38:53AM -0800, Doug Barton wrote:
D> > I saw this too, when my kernel and userland were out of sync (e.g. just
D> > after installing a new kernel, and before installworld). I suspect it
D> > is caused by the changes in r228571, which cause old ifconfig and
D> >
On 20. Dec 2011, at 16:51 , Brooks Davis wrote:
> On Tue, Dec 20, 2011 at 04:43:21PM +0100, Dimitry Andric wrote:
>> On 2011-12-20 09:38, Doug Barton wrote:
>> ...
>>> I tried replacing both ifconfig and dhclient with the versions that were
>>> built along with the new kernel, and that didn't work
On Tue, Dec 20, 2011 at 04:43:21PM +0100, Dimitry Andric wrote:
> On 2011-12-20 09:38, Doug Barton wrote:
> ...
> > I tried replacing both ifconfig and dhclient with the versions that were
> > built along with the new kernel, and that didn't work.
>
> Looking at the changes in r228571, it seems th
On 2011-12-20 09:38, Doug Barton wrote:
...
I tried replacing both ifconfig and dhclient with the versions that were
built along with the new kernel, and that didn't work.
Looking at the changes in r228571, it seems they also affect libc, so
installing that is probably also needed. Since all m
On 12/19/2011 05:24, Dimitry Andric wrote:
> On 2011-12-19 10:17, Doug Barton wrote:
>> I updated to r228700 from 228122 and dhclient exits immediately saying
>> that em0 doesn't exist. However ifconfig seems to disagree:
>>
>>
>> em0: flags=8843 metric 0 mtu
>> 1500
>>
>> options=4219b
>>
>>
On 2011-12-19 17:36, Garrett Cooper wrote:
On Dec 19, 2011, at 5:24 AM, Dimitry Andric wrote:
On 2011-12-19 10:17, Doug Barton wrote:
I updated to r228700 from 228122 and dhclient exits immediately saying
that em0 doesn't exist. However ifconfig seems to disagree:
...
I saw this too, when my
On Dec 19, 2011, at 5:24 AM, Dimitry Andric wrote:
> On 2011-12-19 10:17, Doug Barton wrote:
>> I updated to r228700 from 228122 and dhclient exits immediately saying
>> that em0 doesn't exist. However ifconfig seems to disagree:
>>
>>
>> em0: flags=8843 metric 0 mtu 1500
>>
>> options=4219b
On 2011-12-19 10:17, Doug Barton wrote:
I updated to r228700 from 228122 and dhclient exits immediately saying
that em0 doesn't exist. However ifconfig seems to disagree:
em0: flags=8843 metric 0 mtu 1500
options=4219b
ether 00:24:e8:30:10:9b
nd6 options=29
media: E
I updated to r228700 from 228122 and dhclient exits immediately saying
that em0 doesn't exist. However ifconfig seems to disagree:
em0: flags=8843 metric 0 mtu 1500
options=4219b
ether 00:24:e8:30:10:9b
nd6 options=29
media: Ethernet autoselect (100baseTX )
status
27 matches
Mail list logo
