Re: svn commit: r311849 - in head: . sys/amd64/conf sys/arm64/conf sys/conf sys/dev/e1000 sys/i386/conf sys/mips/conf sys/modules sys/modules/em sys/modules/igb sys/powerpc/conf

[Sean Bruno]

On 03/10/17 13:21, John Baldwin wrote:
> On Friday, March 10, 2017 11:12:45 AM Navdeep Parhar wrote:
>> On Fri, Mar 10, 2017 at 10:41 AM, Ryan Stone  wrote:
>>> There's also the issue that running "ifconfig igb0 blah" during startup will
>>> cause if_igb to be automatically loaded by ifconfig.
>>>
>>> I guess we could add a dummy if_igb.ko that just has a dependency on
>>> if_em.ko
>>
>> I do similar stuff in cxgbe (if_cxl.ko and if_cc.ko exist solely to
>> drag in if_cxgbe.ko as a dependency).  In hindsight I wish I'd just
>> added a list of ifnet names -> kld map to ifconfig instead.  It would
>> have been an ugly hack but much simpler.
> 
> For now I think having an if_igb.c that is like if_cc.c and if_cxl.c
> is probably the simplest way to go.
> 

Gotcha. Will do.

sean



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r311849 - in head: . sys/amd64/conf sys/arm64/conf sys/conf sys/dev/e1000 sys/i386/conf sys/mips/conf sys/modules sys/modules/em sys/modules/igb sys/powerpc/conf

[Warner Losh]

On Fri, Mar 10, 2017 at 1:21 PM, John Baldwin  wrote:
> On Friday, March 10, 2017 11:12:45 AM Navdeep Parhar wrote:
>> On Fri, Mar 10, 2017 at 10:41 AM, Ryan Stone  wrote:
>> > There's also the issue that running "ifconfig igb0 blah" during startup 
>> > will
>> > cause if_igb to be automatically loaded by ifconfig.
>> >
>> > I guess we could add a dummy if_igb.ko that just has a dependency on
>> > if_em.ko
>>
>> I do similar stuff in cxgbe (if_cxl.ko and if_cc.ko exist solely to
>> drag in if_cxgbe.ko as a dependency).  In hindsight I wish I'd just
>> added a list of ifnet names -> kld map to ifconfig instead.  It would
>> have been an ugly hack but much simpler.
>
> For now I think having an if_igb.c that is like if_cc.c and if_cxl.c
> is probably the simplest way to go.

It's certainly the easiest way forward. + if_igb.ko module, right?

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r311849 - in head: . sys/amd64/conf sys/arm64/conf sys/conf sys/dev/e1000 sys/i386/conf sys/mips/conf sys/modules sys/modules/em sys/modules/igb sys/powerpc/conf

[John Baldwin]

On Friday, March 10, 2017 11:12:45 AM Navdeep Parhar wrote:
> On Fri, Mar 10, 2017 at 10:41 AM, Ryan Stone  wrote:
> > There's also the issue that running "ifconfig igb0 blah" during startup will
> > cause if_igb to be automatically loaded by ifconfig.
> >
> > I guess we could add a dummy if_igb.ko that just has a dependency on
> > if_em.ko
> 
> I do similar stuff in cxgbe (if_cxl.ko and if_cc.ko exist solely to
> drag in if_cxgbe.ko as a dependency).  In hindsight I wish I'd just
> added a list of ifnet names -> kld map to ifconfig instead.  It would
> have been an ugly hack but much simpler.

For now I think having an if_igb.c that is like if_cc.c and if_cxl.c
is probably the simplest way to go.

-- 
John Baldwin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r311849 - in head: . sys/amd64/conf sys/arm64/conf sys/conf sys/dev/e1000 sys/i386/conf sys/mips/conf sys/modules sys/modules/em sys/modules/igb sys/powerpc/conf

[Warner Losh]

On Fri, Mar 10, 2017 at 1:10 PM, Adrian Chadd  wrote:
> On 10 March 2017 at 12:09, Warner Losh  wrote:
>> It's already in loader.hints. The bug is that ifconfig doesn't use a
>> library (which others can use) to find the module by name, but rather
>> assumes a particular filename -> module name mapping.
>
> Sounds like a GSoC project. :-)

Done properly, it could also solve the auto-loading of drivers issue
:) Many of the pieces are there, though marking pci drivers would need
to be done in earnest.

Warner

>
> -adrian
>
>> Warner
>>
>> On Fri, Mar 10, 2017 at 1:07 PM, Adrian Chadd  wrote:
>>> s/ifconfig/put-it-in-a-config-file-in-share-so-we-dont-have-to-patch-ifconfig-every-time-we-change-this-kthxbai/g
>>>
>>>
>>> -adrian
>>>
>>>
>>> On 10 March 2017 at 11:12, Navdeep Parhar  wrote:
 On Fri, Mar 10, 2017 at 10:41 AM, Ryan Stone  wrote:
> There's also the issue that running "ifconfig igb0 blah" during startup 
> will
> cause if_igb to be automatically loaded by ifconfig.
>
> I guess we could add a dummy if_igb.ko that just has a dependency on
> if_em.ko

 I do similar stuff in cxgbe (if_cxl.ko and if_cc.ko exist solely to
 drag in if_cxgbe.ko as a dependency).  In hindsight I wish I'd just
 added a list of ifnet names -> kld map to ifconfig instead.  It would
 have been an ugly hack but much simpler.

 Regards,
 Navdeep

>
> On Fri, Mar 10, 2017 at 1:13 PM, Warner Losh  wrote:
>>
>> On Fri, Mar 10, 2017 at 11:06 AM, Sean Bruno  wrote:
>> >
>> >
>> > On 02/15/17 03:06, Roger Pau Monné wrote:
>> >> On Tue, Jan 10, 2017 at 03:23:22AM +, Sean Bruno wrote:
>> >>> Author: sbruno
>> >>> Date: Tue Jan 10 03:23:22 2017
>> >>> New Revision: 311849
>> >>> URL: https://svnweb.freebsd.org/changeset/base/311849
>> >>>
>> >>> Log:
>> >>>   Migrate e1000 to the IFLIB framework:
>> >>>   - em(4) igb(4) and lem(4)
>> >>>   - deprecate the igb device from kernel configurations
>> >>>   - create a symbolic link in /boot/kernel from if_em.ko to if_igb.ko
>> >>
>> >> This linking causes mfsBSD to choke when building an image from HEAD.
>> >> It tries
>> >> to issue the following command:
>> >>
>> >> ${_v}${CP} -rp ${_BOOTDIR}/kernel ${WRKDIR}/disk/boot
>> >>
>> >> Which fails when finding the symbol link. I can send a patch to change
>> >> that to
>> >> -Rp, which would work fine, but wouldn't it be better to either
>> >> completely
>> >> remove if_igb.ko, or simply copy if_em.ko to if_igb.ko?
>> >>
>> >> I'm wondering if for example anyone strips down it's /boot/kernel/
>> >> manually, by
>> >> removing unused modules, and what would happen if if_em.ko is removed
>> >> but not
>> >> if_igb.ko.
>> >>
>> >> Roger.
>> >>
>> >>
>> >
>> > Well, this was my naive attempt to make upgrades for users to be
>> > non-eventful in the event they have "if_igb_load=YES" in their
>> > loader.conf instead of having it built into their kernel.
>> >
>> > If the -Rp works, I'll add that instead.
>>
>> The module name is encoded in the module itself. The boot loader looks
>> it up to see which module to load. Maybe there's a way to fix it so
>> both load from one file?
>>
>> Warner
>>
>

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r311849 - in head: . sys/amd64/conf sys/arm64/conf sys/conf sys/dev/e1000 sys/i386/conf sys/mips/conf sys/modules sys/modules/em sys/modules/igb sys/powerpc/conf

[Adrian Chadd]

On 10 March 2017 at 12:09, Warner Losh  wrote:
> It's already in loader.hints. The bug is that ifconfig doesn't use a
> library (which others can use) to find the module by name, but rather
> assumes a particular filename -> module name mapping.

Sounds like a GSoC project. :-)



-adrian

> Warner
>
> On Fri, Mar 10, 2017 at 1:07 PM, Adrian Chadd  wrote:
>> s/ifconfig/put-it-in-a-config-file-in-share-so-we-dont-have-to-patch-ifconfig-every-time-we-change-this-kthxbai/g
>>
>>
>> -adrian
>>
>>
>> On 10 March 2017 at 11:12, Navdeep Parhar  wrote:
>>> On Fri, Mar 10, 2017 at 10:41 AM, Ryan Stone  wrote:
 There's also the issue that running "ifconfig igb0 blah" during startup 
 will
 cause if_igb to be automatically loaded by ifconfig.

 I guess we could add a dummy if_igb.ko that just has a dependency on
 if_em.ko
>>>
>>> I do similar stuff in cxgbe (if_cxl.ko and if_cc.ko exist solely to
>>> drag in if_cxgbe.ko as a dependency).  In hindsight I wish I'd just
>>> added a list of ifnet names -> kld map to ifconfig instead.  It would
>>> have been an ugly hack but much simpler.
>>>
>>> Regards,
>>> Navdeep
>>>

 On Fri, Mar 10, 2017 at 1:13 PM, Warner Losh  wrote:
>
> On Fri, Mar 10, 2017 at 11:06 AM, Sean Bruno  wrote:
> >
> >
> > On 02/15/17 03:06, Roger Pau Monné wrote:
> >> On Tue, Jan 10, 2017 at 03:23:22AM +, Sean Bruno wrote:
> >>> Author: sbruno
> >>> Date: Tue Jan 10 03:23:22 2017
> >>> New Revision: 311849
> >>> URL: https://svnweb.freebsd.org/changeset/base/311849
> >>>
> >>> Log:
> >>>   Migrate e1000 to the IFLIB framework:
> >>>   - em(4) igb(4) and lem(4)
> >>>   - deprecate the igb device from kernel configurations
> >>>   - create a symbolic link in /boot/kernel from if_em.ko to if_igb.ko
> >>
> >> This linking causes mfsBSD to choke when building an image from HEAD.
> >> It tries
> >> to issue the following command:
> >>
> >> ${_v}${CP} -rp ${_BOOTDIR}/kernel ${WRKDIR}/disk/boot
> >>
> >> Which fails when finding the symbol link. I can send a patch to change
> >> that to
> >> -Rp, which would work fine, but wouldn't it be better to either
> >> completely
> >> remove if_igb.ko, or simply copy if_em.ko to if_igb.ko?
> >>
> >> I'm wondering if for example anyone strips down it's /boot/kernel/
> >> manually, by
> >> removing unused modules, and what would happen if if_em.ko is removed
> >> but not
> >> if_igb.ko.
> >>
> >> Roger.
> >>
> >>
> >
> > Well, this was my naive attempt to make upgrades for users to be
> > non-eventful in the event they have "if_igb_load=YES" in their
> > loader.conf instead of having it built into their kernel.
> >
> > If the -Rp works, I'll add that instead.
>
> The module name is encoded in the module itself. The boot loader looks
> it up to see which module to load. Maybe there's a way to fix it so
> both load from one file?
>
> Warner
>

>>>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r311849 - in head: . sys/amd64/conf sys/arm64/conf sys/conf sys/dev/e1000 sys/i386/conf sys/mips/conf sys/modules sys/modules/em sys/modules/igb sys/powerpc/conf

[Warner Losh]

It's already in loader.hints. The bug is that ifconfig doesn't use a
library (which others can use) to find the module by name, but rather
assumes a particular filename -> module name mapping.

Warner

On Fri, Mar 10, 2017 at 1:07 PM, Adrian Chadd  wrote:
> s/ifconfig/put-it-in-a-config-file-in-share-so-we-dont-have-to-patch-ifconfig-every-time-we-change-this-kthxbai/g
>
>
> -adrian
>
>
> On 10 March 2017 at 11:12, Navdeep Parhar  wrote:
>> On Fri, Mar 10, 2017 at 10:41 AM, Ryan Stone  wrote:
>>> There's also the issue that running "ifconfig igb0 blah" during startup will
>>> cause if_igb to be automatically loaded by ifconfig.
>>>
>>> I guess we could add a dummy if_igb.ko that just has a dependency on
>>> if_em.ko
>>
>> I do similar stuff in cxgbe (if_cxl.ko and if_cc.ko exist solely to
>> drag in if_cxgbe.ko as a dependency).  In hindsight I wish I'd just
>> added a list of ifnet names -> kld map to ifconfig instead.  It would
>> have been an ugly hack but much simpler.
>>
>> Regards,
>> Navdeep
>>
>>>
>>> On Fri, Mar 10, 2017 at 1:13 PM, Warner Losh  wrote:

 On Fri, Mar 10, 2017 at 11:06 AM, Sean Bruno  wrote:
 >
 >
 > On 02/15/17 03:06, Roger Pau Monné wrote:
 >> On Tue, Jan 10, 2017 at 03:23:22AM +, Sean Bruno wrote:
 >>> Author: sbruno
 >>> Date: Tue Jan 10 03:23:22 2017
 >>> New Revision: 311849
 >>> URL: https://svnweb.freebsd.org/changeset/base/311849
 >>>
 >>> Log:
 >>>   Migrate e1000 to the IFLIB framework:
 >>>   - em(4) igb(4) and lem(4)
 >>>   - deprecate the igb device from kernel configurations
 >>>   - create a symbolic link in /boot/kernel from if_em.ko to if_igb.ko
 >>
 >> This linking causes mfsBSD to choke when building an image from HEAD.
 >> It tries
 >> to issue the following command:
 >>
 >> ${_v}${CP} -rp ${_BOOTDIR}/kernel ${WRKDIR}/disk/boot
 >>
 >> Which fails when finding the symbol link. I can send a patch to change
 >> that to
 >> -Rp, which would work fine, but wouldn't it be better to either
 >> completely
 >> remove if_igb.ko, or simply copy if_em.ko to if_igb.ko?
 >>
 >> I'm wondering if for example anyone strips down it's /boot/kernel/
 >> manually, by
 >> removing unused modules, and what would happen if if_em.ko is removed
 >> but not
 >> if_igb.ko.
 >>
 >> Roger.
 >>
 >>
 >
 > Well, this was my naive attempt to make upgrades for users to be
 > non-eventful in the event they have "if_igb_load=YES" in their
 > loader.conf instead of having it built into their kernel.
 >
 > If the -Rp works, I'll add that instead.

 The module name is encoded in the module itself. The boot loader looks
 it up to see which module to load. Maybe there's a way to fix it so
 both load from one file?

 Warner

>>>
>>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r311849 - in head: . sys/amd64/conf sys/arm64/conf sys/conf sys/dev/e1000 sys/i386/conf sys/mips/conf sys/modules sys/modules/em sys/modules/igb sys/powerpc/conf

[Adrian Chadd]

s/ifconfig/put-it-in-a-config-file-in-share-so-we-dont-have-to-patch-ifconfig-every-time-we-change-this-kthxbai/g


-adrian


On 10 March 2017 at 11:12, Navdeep Parhar  wrote:
> On Fri, Mar 10, 2017 at 10:41 AM, Ryan Stone  wrote:
>> There's also the issue that running "ifconfig igb0 blah" during startup will
>> cause if_igb to be automatically loaded by ifconfig.
>>
>> I guess we could add a dummy if_igb.ko that just has a dependency on
>> if_em.ko
>
> I do similar stuff in cxgbe (if_cxl.ko and if_cc.ko exist solely to
> drag in if_cxgbe.ko as a dependency).  In hindsight I wish I'd just
> added a list of ifnet names -> kld map to ifconfig instead.  It would
> have been an ugly hack but much simpler.
>
> Regards,
> Navdeep
>
>>
>> On Fri, Mar 10, 2017 at 1:13 PM, Warner Losh  wrote:
>>>
>>> On Fri, Mar 10, 2017 at 11:06 AM, Sean Bruno  wrote:
>>> >
>>> >
>>> > On 02/15/17 03:06, Roger Pau Monné wrote:
>>> >> On Tue, Jan 10, 2017 at 03:23:22AM +, Sean Bruno wrote:
>>> >>> Author: sbruno
>>> >>> Date: Tue Jan 10 03:23:22 2017
>>> >>> New Revision: 311849
>>> >>> URL: https://svnweb.freebsd.org/changeset/base/311849
>>> >>>
>>> >>> Log:
>>> >>>   Migrate e1000 to the IFLIB framework:
>>> >>>   - em(4) igb(4) and lem(4)
>>> >>>   - deprecate the igb device from kernel configurations
>>> >>>   - create a symbolic link in /boot/kernel from if_em.ko to if_igb.ko
>>> >>
>>> >> This linking causes mfsBSD to choke when building an image from HEAD.
>>> >> It tries
>>> >> to issue the following command:
>>> >>
>>> >> ${_v}${CP} -rp ${_BOOTDIR}/kernel ${WRKDIR}/disk/boot
>>> >>
>>> >> Which fails when finding the symbol link. I can send a patch to change
>>> >> that to
>>> >> -Rp, which would work fine, but wouldn't it be better to either
>>> >> completely
>>> >> remove if_igb.ko, or simply copy if_em.ko to if_igb.ko?
>>> >>
>>> >> I'm wondering if for example anyone strips down it's /boot/kernel/
>>> >> manually, by
>>> >> removing unused modules, and what would happen if if_em.ko is removed
>>> >> but not
>>> >> if_igb.ko.
>>> >>
>>> >> Roger.
>>> >>
>>> >>
>>> >
>>> > Well, this was my naive attempt to make upgrades for users to be
>>> > non-eventful in the event they have "if_igb_load=YES" in their
>>> > loader.conf instead of having it built into their kernel.
>>> >
>>> > If the -Rp works, I'll add that instead.
>>>
>>> The module name is encoded in the module itself. The boot loader looks
>>> it up to see which module to load. Maybe there's a way to fix it so
>>> both load from one file?
>>>
>>> Warner
>>>
>>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r311849 - in head: . sys/amd64/conf sys/arm64/conf sys/conf sys/dev/e1000 sys/i386/conf sys/mips/conf sys/modules sys/modules/em sys/modules/igb sys/powerpc/conf

[Navdeep Parhar]

On Fri, Mar 10, 2017 at 10:41 AM, Ryan Stone  wrote:
> There's also the issue that running "ifconfig igb0 blah" during startup will
> cause if_igb to be automatically loaded by ifconfig.
>
> I guess we could add a dummy if_igb.ko that just has a dependency on
> if_em.ko

I do similar stuff in cxgbe (if_cxl.ko and if_cc.ko exist solely to
drag in if_cxgbe.ko as a dependency).  In hindsight I wish I'd just
added a list of ifnet names -> kld map to ifconfig instead.  It would
have been an ugly hack but much simpler.

Regards,
Navdeep

>
> On Fri, Mar 10, 2017 at 1:13 PM, Warner Losh  wrote:
>>
>> On Fri, Mar 10, 2017 at 11:06 AM, Sean Bruno  wrote:
>> >
>> >
>> > On 02/15/17 03:06, Roger Pau Monné wrote:
>> >> On Tue, Jan 10, 2017 at 03:23:22AM +, Sean Bruno wrote:
>> >>> Author: sbruno
>> >>> Date: Tue Jan 10 03:23:22 2017
>> >>> New Revision: 311849
>> >>> URL: https://svnweb.freebsd.org/changeset/base/311849
>> >>>
>> >>> Log:
>> >>>   Migrate e1000 to the IFLIB framework:
>> >>>   - em(4) igb(4) and lem(4)
>> >>>   - deprecate the igb device from kernel configurations
>> >>>   - create a symbolic link in /boot/kernel from if_em.ko to if_igb.ko
>> >>
>> >> This linking causes mfsBSD to choke when building an image from HEAD.
>> >> It tries
>> >> to issue the following command:
>> >>
>> >> ${_v}${CP} -rp ${_BOOTDIR}/kernel ${WRKDIR}/disk/boot
>> >>
>> >> Which fails when finding the symbol link. I can send a patch to change
>> >> that to
>> >> -Rp, which would work fine, but wouldn't it be better to either
>> >> completely
>> >> remove if_igb.ko, or simply copy if_em.ko to if_igb.ko?
>> >>
>> >> I'm wondering if for example anyone strips down it's /boot/kernel/
>> >> manually, by
>> >> removing unused modules, and what would happen if if_em.ko is removed
>> >> but not
>> >> if_igb.ko.
>> >>
>> >> Roger.
>> >>
>> >>
>> >
>> > Well, this was my naive attempt to make upgrades for users to be
>> > non-eventful in the event they have "if_igb_load=YES" in their
>> > loader.conf instead of having it built into their kernel.
>> >
>> > If the -Rp works, I'll add that instead.
>>
>> The module name is encoded in the module itself. The boot loader looks
>> it up to see which module to load. Maybe there's a way to fix it so
>> both load from one file?
>>
>> Warner
>>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r311849 - in head: . sys/amd64/conf sys/arm64/conf sys/conf sys/dev/e1000 sys/i386/conf sys/mips/conf sys/modules sys/modules/em sys/modules/igb sys/powerpc/conf

[Ryan Stone]

There's also the issue that running "ifconfig igb0 blah" during startup
will cause if_igb to be automatically loaded by ifconfig.

I guess we could add a dummy if_igb.ko that just has a dependency on
if_em.ko

On Fri, Mar 10, 2017 at 1:13 PM, Warner Losh  wrote:

> On Fri, Mar 10, 2017 at 11:06 AM, Sean Bruno  wrote:
> >
> >
> > On 02/15/17 03:06, Roger Pau Monné wrote:
> >> On Tue, Jan 10, 2017 at 03:23:22AM +, Sean Bruno wrote:
> >>> Author: sbruno
> >>> Date: Tue Jan 10 03:23:22 2017
> >>> New Revision: 311849
> >>> URL: https://svnweb.freebsd.org/changeset/base/311849
> >>>
> >>> Log:
> >>>   Migrate e1000 to the IFLIB framework:
> >>>   - em(4) igb(4) and lem(4)
> >>>   - deprecate the igb device from kernel configurations
> >>>   - create a symbolic link in /boot/kernel from if_em.ko to if_igb.ko
> >>
> >> This linking causes mfsBSD to choke when building an image from HEAD.
> It tries
> >> to issue the following command:
> >>
> >> ${_v}${CP} -rp ${_BOOTDIR}/kernel ${WRKDIR}/disk/boot
> >>
> >> Which fails when finding the symbol link. I can send a patch to change
> that to
> >> -Rp, which would work fine, but wouldn't it be better to either
> completely
> >> remove if_igb.ko, or simply copy if_em.ko to if_igb.ko?
> >>
> >> I'm wondering if for example anyone strips down it's /boot/kernel/
> manually, by
> >> removing unused modules, and what would happen if if_em.ko is removed
> but not
> >> if_igb.ko.
> >>
> >> Roger.
> >>
> >>
> >
> > Well, this was my naive attempt to make upgrades for users to be
> > non-eventful in the event they have "if_igb_load=YES" in their
> > loader.conf instead of having it built into their kernel.
> >
> > If the -Rp works, I'll add that instead.
>
> The module name is encoded in the module itself. The boot loader looks
> it up to see which module to load. Maybe there's a way to fix it so
> both load from one file?
>
> Warner
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r311849 - in head: . sys/amd64/conf sys/arm64/conf sys/conf sys/dev/e1000 sys/i386/conf sys/mips/conf sys/modules sys/modules/em sys/modules/igb sys/powerpc/conf

[Warner Losh]

On Fri, Mar 10, 2017 at 11:06 AM, Sean Bruno  wrote:
>
>
> On 02/15/17 03:06, Roger Pau Monné wrote:
>> On Tue, Jan 10, 2017 at 03:23:22AM +, Sean Bruno wrote:
>>> Author: sbruno
>>> Date: Tue Jan 10 03:23:22 2017
>>> New Revision: 311849
>>> URL: https://svnweb.freebsd.org/changeset/base/311849
>>>
>>> Log:
>>>   Migrate e1000 to the IFLIB framework:
>>>   - em(4) igb(4) and lem(4)
>>>   - deprecate the igb device from kernel configurations
>>>   - create a symbolic link in /boot/kernel from if_em.ko to if_igb.ko
>>
>> This linking causes mfsBSD to choke when building an image from HEAD. It 
>> tries
>> to issue the following command:
>>
>> ${_v}${CP} -rp ${_BOOTDIR}/kernel ${WRKDIR}/disk/boot
>>
>> Which fails when finding the symbol link. I can send a patch to change that 
>> to
>> -Rp, which would work fine, but wouldn't it be better to either completely
>> remove if_igb.ko, or simply copy if_em.ko to if_igb.ko?
>>
>> I'm wondering if for example anyone strips down it's /boot/kernel/ manually, 
>> by
>> removing unused modules, and what would happen if if_em.ko is removed but not
>> if_igb.ko.
>>
>> Roger.
>>
>>
>
> Well, this was my naive attempt to make upgrades for users to be
> non-eventful in the event they have "if_igb_load=YES" in their
> loader.conf instead of having it built into their kernel.
>
> If the -Rp works, I'll add that instead.

The module name is encoded in the module itself. The boot loader looks
it up to see which module to load. Maybe there's a way to fix it so
both load from one file?

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r311849 - in head: . sys/amd64/conf sys/arm64/conf sys/conf sys/dev/e1000 sys/i386/conf sys/mips/conf sys/modules sys/modules/em sys/modules/igb sys/powerpc/conf

[Rodney W. Grimes]

-- Start of PGP signed section.
[ Charset windows-1252 unsupported, converting... ]
> 
> 
> On 02/15/17 03:06, Roger Pau Monn? wrote:
> > On Tue, Jan 10, 2017 at 03:23:22AM +, Sean Bruno wrote:
> >> Author: sbruno
> >> Date: Tue Jan 10 03:23:22 2017
> >> New Revision: 311849
> >> URL: https://svnweb.freebsd.org/changeset/base/311849
> >>
> >> Log:
> >>   Migrate e1000 to the IFLIB framework:
> >>   - em(4) igb(4) and lem(4)
> >>   - deprecate the igb device from kernel configurations
> >>   - create a symbolic link in /boot/kernel from if_em.ko to if_igb.ko

What about if you make that a hard link?
Would that fix the CP issue too?

> > 
> > This linking causes mfsBSD to choke when building an image from HEAD. It 
> > tries
> > to issue the following command:
> > 
> > ${_v}${CP} -rp ${_BOOTDIR}/kernel ${WRKDIR}/disk/boot
> > 
> > Which fails when finding the symbol link. I can send a patch to change that 
> > to
> > -Rp, which would work fine, but wouldn't it be better to either completely
> > remove if_igb.ko, or simply copy if_em.ko to if_igb.ko?
> > 
> > I'm wondering if for example anyone strips down it's /boot/kernel/ 
> > manually, by
> > removing unused modules, and what would happen if if_em.ko is removed but 
> > not
> > if_igb.ko.
> > 
> > Roger.
> > 
> > 
> 
> Well, this was my naive attempt to make upgrades for users to be
> non-eventful in the event they have "if_igb_load=YES" in their
> loader.conf instead of having it built into their kernel.
> 
> If the -Rp works, I'll add that instead.
> 
> sean
> 
-- End of PGP section, PGP failed!

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r311849 - in head: . sys/amd64/conf sys/arm64/conf sys/conf sys/dev/e1000 sys/i386/conf sys/mips/conf sys/modules sys/modules/em sys/modules/igb sys/powerpc/conf

[Sean Bruno]

On 02/15/17 03:06, Roger Pau Monné wrote:
> On Tue, Jan 10, 2017 at 03:23:22AM +, Sean Bruno wrote:
>> Author: sbruno
>> Date: Tue Jan 10 03:23:22 2017
>> New Revision: 311849
>> URL: https://svnweb.freebsd.org/changeset/base/311849
>>
>> Log:
>>   Migrate e1000 to the IFLIB framework:
>>   - em(4) igb(4) and lem(4)
>>   - deprecate the igb device from kernel configurations
>>   - create a symbolic link in /boot/kernel from if_em.ko to if_igb.ko
> 
> This linking causes mfsBSD to choke when building an image from HEAD. It tries
> to issue the following command:
> 
> ${_v}${CP} -rp ${_BOOTDIR}/kernel ${WRKDIR}/disk/boot
> 
> Which fails when finding the symbol link. I can send a patch to change that to
> -Rp, which would work fine, but wouldn't it be better to either completely
> remove if_igb.ko, or simply copy if_em.ko to if_igb.ko?
> 
> I'm wondering if for example anyone strips down it's /boot/kernel/ manually, 
> by
> removing unused modules, and what would happen if if_em.ko is removed but not
> if_igb.ko.
> 
> Roger.
> 
> 

Well, this was my naive attempt to make upgrades for users to be
non-eventful in the event they have "if_igb_load=YES" in their
loader.conf instead of having it built into their kernel.

If the -Rp works, I'll add that instead.

sean



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r311849 - in head: . sys/amd64/conf sys/arm64/conf sys/conf sys/dev/e1000 sys/i386/conf sys/mips/conf sys/modules sys/modules/em sys/modules/igb sys/powerpc/conf

[Mark Millard]

> Author: sbruno
> Date: Tue Jan 10 03:23:22 2017
> New Revision: 311849
> URL: https://svnweb.freebsd.org/changeset/base/311849
> 
> Log:
>   Migrate e1000 to the IFLIB framework:
>   . . .
>   - create a symbolic link in /boot/kernel from if_em.ko to if_igb.ko

If one used DESTDIR= pointing to a local directory for a cross
built installkernel for later copying to the system(s) that will
use the kernel one gets such things as:

# ls -l /usr/obj/DESTDIRs/clang-pine64-installkernel/boot/kernel/if_igb.ko 
lrwxr-xr-x  1 root  wheel  65 Feb 14 09:25 
/usr/obj/DESTDIRs/clang-pine64-installkernel/boot/kernel/if_igb.ko -> 
/usr/obj/DESTDIRs/clang-pine64-installkernel/boot/kernel/if_em.ko

But the target place(s) to later copy to is(are) unlikely to
have such a path.

Relative paths, hard links, or independent copies could avoid
such things.

===
Mark Millard
markmi at dsl-only.net

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r311849 - in head: . sys/amd64/conf sys/arm64/conf sys/conf sys/dev/e1000 sys/i386/conf sys/mips/conf sys/modules sys/modules/em sys/modules/igb sys/powerpc/conf

[Roger Pau Monné]

On Tue, Jan 10, 2017 at 03:23:22AM +, Sean Bruno wrote:
> Author: sbruno
> Date: Tue Jan 10 03:23:22 2017
> New Revision: 311849
> URL: https://svnweb.freebsd.org/changeset/base/311849
> 
> Log:
>   Migrate e1000 to the IFLIB framework:
>   - em(4) igb(4) and lem(4)
>   - deprecate the igb device from kernel configurations
>   - create a symbolic link in /boot/kernel from if_em.ko to if_igb.ko

This linking causes mfsBSD to choke when building an image from HEAD. It tries
to issue the following command:

${_v}${CP} -rp ${_BOOTDIR}/kernel ${WRKDIR}/disk/boot

Which fails when finding the symbol link. I can send a patch to change that to
-Rp, which would work fine, but wouldn't it be better to either completely
remove if_igb.ko, or simply copy if_em.ko to if_igb.ko?

I'm wondering if for example anyone strips down it's /boot/kernel/ manually, by
removing unused modules, and what would happen if if_em.ko is removed but not
if_igb.ko.

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"