Re: if_igb.ko symbolic link generation is still messed up in that it hard wires the path at installkernel time, messing up copying to other places

On Sat, 2017-09-09 at 15:31 -0700, Simon J. Gerraty wrote: > Mark Millard wrote: > > > > # ls -lTt /media/boot/kernel/if_igb.ko /mnt/boot/kerndb/if_igb.ko > > lrwxr-xr-x  1 root  wheel  25 Sep  8 22:47:36 2017 > > /mnt/boot/kerndb/if_igb.ko -> /mnt/boot/kernel/if_em.ko > >

Re: FCP-100: armv7 plan

On 9/9/17 3:25 PM, Jan Beich wrote: > Warner Losh writes: > >> On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: >> >>> Warner Losh writes: >> The goal, if it doesn't work already, is for NEON to work if used, >> but not be required, just

Re: if_igb.ko symbolic link generation is still messed up in that it hard wires the path at installkernel time, messing up copying to other places

Mark Millard wrote: > # ls -lTt /media/boot/kernel/if_igb.ko /mnt/boot/kerndb/if_igb.ko > lrwxr-xr-x 1 root wheel 25 Sep 8 22:47:36 2017 /mnt/boot/kerndb/if_igb.ko > -> /mnt/boot/kernel/if_em.ko > lrwxr-xr-x 1 root wheel 68 Sep 6 20:27:20 2017 >

Getauxval - was Re: FCP-100: armv7 plan

Apologies for the top post.  Man pages indicate ‎getauxval is a non standard glibc function. Is this an issue? Is there a more posix way I could compare against? I was previously wondering to myself if the Linux api is now more standard than the posix api? Looking forward to all opinions and

Re: FCP-100: armv7 plan

On Sat, Sep 09, 2017 at 02:34:10PM -0600, Ian Lepore wrote: > Adding the AT_HWCAP stuff would be relatively easy.  I'm not as sure > what to do about getauxval().  To be maximally linux-compatible (which > would be good for ports) we'd put getauxval() in libc and make it work > just like the linux

Re: FCP-100: armv7 plan

On Sat, Sep 9, 2017 at 2:34 PM, Ian Lepore wrote: > On Sat, 2017-09-09 at 21:25 +0200, Jan Beich wrote: > > Warner Losh writes: > > > > > > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich > > > wrote: > > > > > > > > > > > Warner Losh

Re: FCP-100: armv7 plan

On Sat, 2017-09-09 at 21:25 +0200, Jan Beich wrote: > Warner Losh writes: > > > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich > > wrote: > > > > > > > > Warner Losh writes: > > > > > > > > > > > Greetings, > > > > > > > > This will

Re: FCP-100: armv7 plan

Warner,  So you are saying NEON support is a compile time option that has no relevance to the Application Binary Interface, which is what the FCP-0100 was about? Thanks for clarification, Russ Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.   Original Message   From: Warner

if_igb.ko symbolic link generation is still messed up in that it hard wires the path at installkernel time, messing up copying to other places

[The example here happens to be for amd64 -> aarch64 cross builds.] The following is from after copying/moving the kernel from where it was originally, such as (locally) installed on the build machine. Example of symbolic links from some recent activity under head -r323246 (producing -r323246

Re: FCP-100: armv7 plan

On Sat, Sep 9, 2017 at 1:25 PM, Jan Beich wrote: > Warner Losh writes: > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > > > >> Warner Losh writes: > >> > >> > Greetings, > >> > > >> > This will serve as 'Last

Re: FCP-100: armv7 plan

Warner Losh writes: > Greetings, > > This will serve as 'Last Call' for any objections to the plan to create an > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. [...] Some ports want NEON support but FCP-0100 is vague about FreeBSD-specific differences between armv6