Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-04-01 Thread Mark Millard 
[Just a top-post showing what powerpc64-xtoolchain-gcc/powerpc64-gcc has for 
the default include search places:]

powerpc64-xtoolchain-gcc/powerpc64-gcc also looks in /usr/local/include before 
/usr/include : see below.

> # portmaster --list-origins
> . . .
> devel/powerpc64-xtoolchain-gcc
> . . .
> 
> # /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc --version
> powerpc64-portbld-freebsd11.0-gcc (FreeBSD Ports Collection for powerpc64) 
> 5.3.0
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> # echo '' |/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -v -x c++ - -o 
> /dev/null
> . . .
> ignoring nonexistent directory 
> "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../include/c++/5.3.0"
> ignoring nonexistent directory 
> "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../include/c++/5.3.0/powerpc64-portbld-freebsd11.0"
> ignoring nonexistent directory 
> "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../include/c++/5.3.0/backward"
> ignoring nonexistent directory 
> "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerpc64-portbld-freebsd11.0/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include
>  /usr/local/include
>  /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed
>  /usr/include
> End of search list.
> . . .


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

On 2016-Apr-1, at 7:25 AM, Warner Losh  wrote:
> 
> 
> 
> On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric  wrote:
> On 01 Apr 2016, at 00:44, Warner Losh  wrote:
> >
> >> On Mar 31, 2016, at 4:34 PM, Bryan Drewery  wrote:
> >> I didn't realize the ports compiler was defaulting /usr/local/include
> >> into the search path now.  It does not have /usr/local/lib in the
> >> default library path as far as I can tell.  It's also broken for its
> >> -rpath (noted in its pkg-message).  So having a default
> >> /usr/local/include path seems odd.
> >
> > It has for a while now. It’s one of the maddening inconsistencies that 
> > abound in this
> > area. I took a poll a while ago and there seemed to be widespread support 
> > for adding
> > it to the base compiler.
> 
> This was the main reason /usr/local/include was *not* included in the
> base compiler, otherwise it would unpredictably pick up headers in
> /usr/local/include during builds.  You can never know which conflicting
> headers a certain user has installed in /usr/local/include... :)
> 
> That's why it shouldn't be *FIRST*, not why it shouldn't be there
> at all.
> 
> >> Adding -isystem /usr/include to fix this is probably possible but
> >> there's a risk someone will remove it as redundant.  In this case I wish
> >> /usr/include was first but I'm not sure what impact that would have on
> >> consumers expecting /usr/local/include (and /usr/local/lib) overrides to
> >> work, though they would need to pass a -L /usr/local/lib anyhow and
> >> would likely be passing -I /usr/local/lib too.
> >
> > /usr/include should be first. But it isn’t. That’s another inconsistency 
> > that was found
> > when we looked at /usr/local stuff. Someone recently added /usr/local/bin 
> > to the path,
> > if I recall correctly.
> 
> Isn't that a bit of a bikeshed?  I guess some people would just as well
> prefer /usr/local/include to be first, just like some people prefer
> /usr/local/bin before /usr/bin in their PATH.
> 
> Sigh. No. /usr/local is moving into many different things in the base and 
> ports. We should
> do it in a consistent way. What we have now is not consistent and somewhat 
> brittle.
>  
> In any case, if such paths are added to external compilers, we better
> make sure almost everything in buildworld uses -nostdinc, and specifying
> exactly the include directories we need, and no others.  Cumbersome, but
> maybe for a good cause.
> 
> That's the non-brittle solution here. An over-reliance on defaults makes it
> difficult to ensure other compilers will work, especially ones we don't
> tightly control the defaults for.
> 
> Warner
 


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

Re: 11.0 -r297369: _el_fn_sh_complete missing in buildworld; /usr/obj/. . ./lib/libedit/ has no filecomplete.*

2016-04-01 Thread Bryan Drewery 
On 3/29/16 6:35 PM, Mark Millard wrote:
> Going from 11.0-CURRENT -r297048 to -r297369: buildworld after svnlite update:
> /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/. . . ends up with no 
> filecomplete.*
> but the build tries to use what would be some of its contents 
> (_el_fn_sh_complete)
> 
> The details. . .

FYI this was fixed in r297435.

-- 
Regards,
Bryan Drewery
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

/usr/bin/make segmentation fault

2016-04-01 Thread Roger Marquis 
Don't know how to debug this and cannot post the Makefile in question but it
last worked in 8.4.  In 11-CURRENT Var_Value appears to return NULL at
/usr/src/contrib/bmake/compat.c:621

  Var_Set(IMPSRC, Var_Value(TARGET, gn, ), pgn, 0);

which passes the NULL to Var_Set as the second argument (val) where,
eventually, /usr/src/contrib/bmake/var.c:973

  Buf_AddBytes(>val, strlen(val), val);

the SEGV is generated in strlen.

Any and all pointers appreciated,
Roger


gdb /usr/bin/make
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `make'.
Program terminated with signal 11, Segmentation fault.
#0  0x0045a23f in strlen ()
(gdb) bt
#0  0x0045a23f in strlen ()
#1  0x00419dda in Var_Set (name=, val=, ctxt=,
 flags=) at /usr/src/contrib/bmake/var.c:973
#2  0x00402040 in Compat_Make (gnp=0x800a1c340, pgnp=0x800a1df00)
at /usr/src/contrib/bmake/compat.c:621
#3  0x0041eb38 in Lst_ForEachFrom (l=,
ln=, proc=0x401f80 ,
 d=0x800a1df00) at /usr/src/contrib/bmake/lst.lib/lstForEachFrom.c:104
#4  0x00401ff1 in Compat_Make (gnp=0x800a1df00, pgnp=0x800a1e2c0)
at /usr/src/contrib/bmake/compat.c:509
#5  0x0041eb38 in Lst_ForEachFrom (l=,
ln=, proc=0x401f80 ,
 d=0x800a1e2c0) at /usr/src/contrib/bmake/lst.lib/lstForEachFrom.c:104
#6  0x00401ff1 in Compat_Make (gnp=0x800a1e2c0, pgnp=0x800a1e200)
at /usr/src/contrib/bmake/compat.c:509
#7  0x0041eb38 in Lst_ForEachFrom (l=,
ln=, proc=0x401f80 ,
 d=0x800a1e200) at /usr/src/contrib/bmake/lst.lib/lstForEachFrom.c:104
#8  0x00401ff1 in Compat_Make (gnp=0x800a1e200, pgnp=0x800a1e200)
at /usr/src/contrib/bmake/compat.c:509
#9  0x00402446 in Compat_Run (targs=) at
/usr/src/contrib/bmake/compat.c:725
#10 0x0040c4cb in main (argc=4, argv=) at
/usr/src/contrib/bmake/main.c:1396
#11 0x0040031f in _start ()
#12 0x in ?? ()



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

Re: CURRENT slow and shaky network stability

2016-04-01 Thread O. Hartmann 
Am Fri, 1 Apr 2016 13:37:14 -0700 (PDT)
Don Lewis  schrieb:

> On  1 Apr, O. Hartmann wrote:
> > Am Wed, 30 Mar 2016 00:28:39 -0700 (PDT)
> > Don Lewis  schrieb:  
> 
> >> Do you use tmpfs?  Anything stored in there will get stashed in inactive
> >> memory and/or swap.  
> > [...]
> > 
> > Yes, /var/run  and /tmp are on tmpfs   
> 
> There is probably not enough stashed in /var/run to make a difference,
> but if there is a lot in /tmp, it could bloat the amount of inactive
> memory and cause other things to be pushed to swap.  What does
>   df /tmp
> say?
> 
> Depending on the workload, you might find that the change committed in
> r280963 helps interactivity.

The problems are still present with r297495 and all systems with CURRENT show 
symptoms of
not being very responsive under load, even on the consoles/ssh connections on 
non-X11
systems!

> 
> I still can't explain the ssh connection timeout problems that you are
> seeing.  What does
>   ps lax
> report as the MWCHAN for the stuck ssh and/or sshd processes?
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



pgpyrfvUSQo0P.pgp
Description: OpenPGP digital signature

Re: CURRENT slow and shaky network stability

2016-04-01 Thread Don Lewis 
On  1 Apr, O. Hartmann wrote:
> Am Wed, 30 Mar 2016 00:28:39 -0700 (PDT)
> Don Lewis  schrieb:

>> Do you use tmpfs?  Anything stored in there will get stashed in inactive
>> memory and/or swap.
> [...]
> 
> Yes, /var/run  and /tmp are on tmpfs 

There is probably not enough stashed in /var/run to make a difference,
but if there is a lot in /tmp, it could bloat the amount of inactive
memory and cause other things to be pushed to swap.  What does
df /tmp
say?

Depending on the workload, you might find that the change committed in
r280963 helps interactivity.

I still can't explain the ssh connection timeout problems that you are
seeing.  What does
ps lax
report as the MWCHAN for the stuck ssh and/or sshd processes?

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

Re: CURRENT slow and shaky network stability

2016-04-01 Thread O. Hartmann 
Am Wed, 30 Mar 2016 00:28:39 -0700 (PDT)
Don Lewis  schrieb:

> On 29 Mar, To: ohart...@zedat.fu-berlin.de wrote:
> > On 28 Mar, Don Lewis wrote:  
> >> On 28 Mar, O. Hartmann wrote:  
> >
> >> If I get a chance, I try booting my FreeBSD 11 machine with less RAM to
> >> see if that is a trigger.  
> > 
> > I just tried cranking hw.physmen down to 8 GB on 11.0-CURRENT r297204,
> > GENERIC kernel.  /boot/loader.conf contains:
> >   geom_mirror_load="YES"
> >   kern.geom.label.disk_ident.enable="0"
> >   kern.geom.label.gptid.enable="0"
> >   zfs_load="YES"
> >   vboxdrv_load="YES"
> >   hw.physmem="8G"
> > 
> > /etc/sysctl.conf contains:
> >   kern.ipc.shm_allow_removed=1
> > 
> > No /etc/src.conf and nothing of that should matter in /etc/make.conf.
> > 
> > 
> > This is what I see after running
> > poudriere ports -p whatever -u
> > 
> > last pid:  2102;  load averages:  0.24,  0.52,  0.36up 0+00:06:54  
> > 14:13:51
> > 52 processes:  1 running, 51 sleeping
> > CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> > Mem: 95M Active, 20M Inact, 1145M Wired, 39K Buf, 5580M Free
> > ARC: 595M Total, 256M MFU, 248M MRU, 16K Anon, 14M Header, 78M Other
> > Swap: 40G Total, 40G Free
> > 
> > No swap used, inactive memory low, no interactivity problems.  Next I'll
> > try r297267, which is what I believe you are running.  I scanned the
> > commit logs between r297204 and r297267 and didn't see anything terribly
> > suspicious looking.  
> 
> No problems here with r297267 either.  I did a bunch of small poudriere
> runs since the system was first booted.  Usable RAM is still dialed back
> to 8 GB.  A bit of swap is in use, mostly because nginx, which has been
> unused since the system was booted, got swapped out.  Inactive memory is
> low now that poudriere is done.
> 
> last pid: 75471;  load averages:  0.21,  0.15,  0.19up 0+07:36:07  
> 00:24:00
> 50 processes:  1 running, 49 sleeping
> CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> Mem: 5988K Active, 14M Inact, 2641M Wired, 41K Buf, 4179M Free
> ARC: 790M Total, 575M MFU, 169M MRU, 16K Anon, 9618K Header, 36M Other
> Swap: 40G Total, 50M Used, 40G Free
> 
> Do you use tmpfs?  Anything stored in there will get stashed in inactive
> memory and/or swap.
[...]

Yes, /var/run  and /tmp are on tmpfs 


pgpHDiPWbFV3p.pgp
Description: OpenPGP digital signature

Re: accessing a PCIe register from userspace through kmem or other ways ?

2016-04-01 Thread Konstantin Belousov 
On Fri, Apr 01, 2016 at 12:48:24PM -0400, Ryan Stone wrote:
> That is actually a really good question.  I know that with some recent
> BIOSes if I enabled allocating 64-bit addresses to BARs, the BAR would
> actually be mapped outside of the range of /dev/mem.  From a quick glance
> at libpciaccess, I don't think that it handles this case.  A specific
> mechanism for allowing mmaping of BARs would be useful, I think.

I am not sure what do you mean by 'outside of the range of /dev/mem'.
IMO /dev/mem (not kmem) handles every possible physical address both
for mmap(2) and for read(2)/write(2).  For io interface there were
some bugs, but they are believed to be fixed.  I mean amd64.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: accessing a PCIe register from userspace through kmem or other ways ?

2016-04-01 Thread Ryan Stone 
On Fri, Apr 1, 2016 at 12:31 PM, John Baldwin  wrote:

> Sorry, I mapped PCIe registers to the PCI-e config space register set.  I
> am
> not sure exactly how libpciaccess handles register access (perhaps it reads
> raw bars and maps them via /dev/mem)?  However, it would not be hard to a
> new ioctl to /dev/pci to allow one to mmap a specific BAR of a given
> device.
>

That is actually a really good question.  I know that with some recent
BIOSes if I enabled allocating 64-bit addresses to BARs, the BAR would
actually be mapped outside of the range of /dev/mem.  From a quick glance
at libpciaccess, I don't think that it handles this case.  A specific
mechanism for allowing mmaping of BARs would be useful, I think.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: accessing a PCIe register from userspace through kmem or other ways ?

2016-04-01 Thread John Baldwin 
On Friday, April 01, 2016 01:07:55 PM Luigi Rizzo wrote:
> On Thu, Mar 31, 2016 at 11:55 PM, Ryan Stone  wrote:
> 
> > On Thu, Mar 31, 2016 at 4:39 PM, John Baldwin  wrote:
> >
> >> On Wednesday, March 30, 2016 11:20:51 AM Jim Harris wrote:
> >> > On Wed, Mar 30, 2016 at 10:47 AM, Luigi Rizzo 
> >> wrote:
> >> >
> >> > > Hi,
> >> > > I'd like to test the rate at which I can access device registers
> >> > > on a PCIe card, and was wondering whether I need to patch a device
> >> > > driver, or perhaps I can use /dev/kmem once I figure out where
> >> > > the registers are mapped ?
> >> > >
> >> >
> >> > You do not need to patch a device driver.  Have you looked at
> >> > libpciaccess?  This should give you everything you need.
> >>
> >> You can also look at what pciconf uses.  (It has a read_config() method
> >> that uses an ioctl on an fd of /dev/pci).
> >>
> >
> > pciconf can only access the configuration space, right?  I believe that
> > Luigi is more interested in measuring the latency to a register mapped from
> > a BAR.
> >
> 
> ​Thank you all for you answers, I will look at libpciaccess.
> 
> Yes my goal is to look at the rate and latency for accessing
> BAR-mapped registers

Sorry, I mapped PCIe registers to the PCI-e config space register set.  I am
not sure exactly how libpciaccess handles register access (perhaps it reads
raw bars and maps them via /dev/mem)?  However, it would not be hard to a
new ioctl to /dev/pci to allow one to mmap a specific BAR of a given device.

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

Re: [FreeBSD-Announce] FreeBSD 2.2.9 Released!

2016-04-01 Thread Ruslan Ermilov 
Hi,

At Nginx, we are committed to supporting a wide range of
BSD-like operating systems and their releases.  It's our
great pleasure to report that it's now again possible to
build current nginx sources with FreeBSD 2.2.9.  We know
that many highload setups still use this FreeBSD version.

On Fri, Apr 01, 2016 at 01:45:04PM +, Maxim Dounin wrote:
> details:   http://hg.nginx.org/nginx/rev/8426275a13fd
> branches:  
> changeset: 6500:8426275a13fd
> user:  Maxim Dounin 
> date:  Fri Apr 01 16:38:31 2016 +0300
> description:
> Compatibility with FreeBSD 2.2.9.
> 
> Added (RTLD_NOW | RTLD_GLOBAL) to dlopen() test.  There is no RTLD_GLOBAL
> on FreeBSD 2.2.9.
> 
> Added uint32_t test, with fallback to u_int32_t, similar to uint64_t one.
> Added fallback to u_int32_t in in_addr_t test.
> 
> With these changes it is now possible to compile nginx on FreeBSD 2.2.9
> with only few minor warnings (assuming -Wno-error).

On Sat, Apr 01, 2006 at 01:30:09PM -0700, Scott Long wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> It is my great pleasure and privilege to announce the availability of
> FreeBSD 2.2.9-RELEASE.  This release is the culmination of SEVENTY-SEVEN
> months of tireless work by the FreeBSD developers, users, their children,
> and their pets.  Significant features in this release:
> 
> - - XFree86 3.3.3, the industry leader in support for cutting edge PCI
>   graphics adapters and 2D acceleration.
> - - The 8GB barrier in IDE drive sizes has finally been broken.  The wd(4)
>   driver now supports unimaginable sizes of 137GB on a single drive!
> - - Support for all of the latest high-speed FAST-WIDE (20MB/s) SCSI-2
>   controllers.
> - - The Linux emulator is now able to run Quake2 out-of-the-box.
> 
> A full description of the release can be found here:
> 
>   ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/2.2.9-RELEASE/README.TXT
>   ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/2.2.9-RELEASE/RELNOTES.TXT
>  
> 
>  Availability
>  -
> 
> FreeBSD 2.2.9-RELEASE supports the i386 architecture and can be installed
> directly over the net using bootable media or copied to a local NFS/FTP
> server.
> 
> Please continue to support the FreeBSD Project by purchasing media
> from one of our supporting vendors.  The following companies will be
> offering FreeBSD 2.2.9 based products:
> 
> ~   FreeBSD Mall, Inc.http://www.freebsdmall.com/
> ~   Daemonnews, Inc.  http://www.bsdmall.com/freebsd1.html
> 
> If you can't afford FreeBSD on media, are impatient, or just want to
> use it for evangelism purposes, then by all means download the ISO
> images.  We can't promise that all the mirror sites will carry the
> larger ISO images, but they will at least be available from the
> following sites.
> 
>  FTP
>  ---
> 
> At the time of this announcement the following FTP sites have FreeBSD
> 2.2.9-RELEASE available.
> 
>   ftp://ftp.FreeBSD.org/pub/FreeBSD/releases
> 
> FreeBSD is also available via anonymous FTP from mirror sites in the
> following countries: Argentina, Australia, Brazil, Bulgaria, Canada,
> China, Czech Republic, Denmark, Estonia, Finland, France, Germany,
> Hong Kong, Hungary, Iceland, Ireland, Japan, Korea, Lithuania,
>  the Netherlands, New Zealand, Poland, Portugal, Romania,
> Russia, Saudi Arabia, South Africa, Slovak Republic, Slovenia, Spain,
> Sweden, Taiwan, Thailand, Ukraine, and the United Kingdom.
> 
> Before trying the central FTP site, please check your regional
> mirror(s) first by going to:
> 
> ftp://ftp..FreeBSD.org/pub/FreeBSD
> 
> Any additional mirror sites will be labeled ftp2, ftp3 and so on.
> 
> More information about FreeBSD mirror sites can be found at:
> 
> http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html
> 
> For instructions on installing FreeBSD, please see Chapter 2 of The
> FreeBSD Handbook.  It provides a complete installation walk-through
> for users new to FreeBSD, and can be found online at:
> 
> http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/install.html
> 
>  Acknowledgments
>  
> 
> The release engineering team for 2.2.9-RELEASE includes:
> 
> Scott Long  Release Engineering
> Ruslan Ermilov  I386, creative director
> Sniffy The Wonder Cat Warrm lap, typing assistance
> Max The Dancing Cat   Early morning wakeups, QA
> Sammy The Tiny CatFace licks, QA
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.2 (FreeBSD)
> 
> iD8DBQFELuG+HTr20QF8Xr8RAkoyAJ4nU4v9TK/Tjh8eEGbjNtGxmiVu0gCfcNtg
> oNz6FNHVuv87MSKJeXJcMAU=
> =Z5hh
> -END PGP SIGNATURE-


-- 
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-04-01 Thread Warner Losh 
On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric  wrote:

> On 01 Apr 2016, at 00:44, Warner Losh  wrote:
> >
> >> On Mar 31, 2016, at 4:34 PM, Bryan Drewery 
> wrote:
> >> I didn't realize the ports compiler was defaulting /usr/local/include
> >> into the search path now.  It does not have /usr/local/lib in the
> >> default library path as far as I can tell.  It's also broken for its
> >> -rpath (noted in its pkg-message).  So having a default
> >> /usr/local/include path seems odd.
> >
> > It has for a while now. It’s one of the maddening inconsistencies that
> abound in this
> > area. I took a poll a while ago and there seemed to be widespread
> support for adding
> > it to the base compiler.
>
> This was the main reason /usr/local/include was *not* included in the
> base compiler, otherwise it would unpredictably pick up headers in
> /usr/local/include during builds.  You can never know which conflicting
> headers a certain user has installed in /usr/local/include... :)


That's why it shouldn't be *FIRST*, not why it shouldn't be there
at all.

>> Adding -isystem /usr/include to fix this is probably possible but
> >> there's a risk someone will remove it as redundant.  In this case I wish
> >> /usr/include was first but I'm not sure what impact that would have on
> >> consumers expecting /usr/local/include (and /usr/local/lib) overrides to
> >> work, though they would need to pass a -L /usr/local/lib anyhow and
> >> would likely be passing -I /usr/local/lib too.
> >
> > /usr/include should be first. But it isn’t. That’s another inconsistency
> that was found
> > when we looked at /usr/local stuff. Someone recently added
> /usr/local/bin to the path,
> > if I recall correctly.
>
> Isn't that a bit of a bikeshed?  I guess some people would just as well
> prefer /usr/local/include to be first, just like some people prefer
> /usr/local/bin before /usr/bin in their PATH.
>

Sigh. No. /usr/local is moving into many different things in the base and
ports. We should
do it in a consistent way. What we have now is not consistent and somewhat
brittle.


> In any case, if such paths are added to external compilers, we better
> make sure almost everything in buildworld uses -nostdinc, and specifying
> exactly the include directories we need, and no others.  Cumbersome, but
> maybe for a good cause.


That's the non-brittle solution here. An over-reliance on defaults makes it
difficult to ensure other compilers will work, especially ones we don't
tightly control the defaults for.

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

Re: accessing a PCIe register from userspace through kmem or other ways ?

2016-04-01 Thread Luigi Rizzo 
On Thu, Mar 31, 2016 at 11:55 PM, Ryan Stone  wrote:

> On Thu, Mar 31, 2016 at 4:39 PM, John Baldwin  wrote:
>
>> On Wednesday, March 30, 2016 11:20:51 AM Jim Harris wrote:
>> > On Wed, Mar 30, 2016 at 10:47 AM, Luigi Rizzo 
>> wrote:
>> >
>> > > Hi,
>> > > I'd like to test the rate at which I can access device registers
>> > > on a PCIe card, and was wondering whether I need to patch a device
>> > > driver, or perhaps I can use /dev/kmem once I figure out where
>> > > the registers are mapped ?
>> > >
>> >
>> > You do not need to patch a device driver.  Have you looked at
>> > libpciaccess?  This should give you everything you need.
>>
>> You can also look at what pciconf uses.  (It has a read_config() method
>> that uses an ioctl on an fd of /dev/pci).
>>
>
> pciconf can only access the configuration space, right?  I believe that
> Luigi is more interested in measuring the latency to a register mapped from
> a BAR.
>

​Thank you all for you answers, I will look at libpciaccess.

Yes my goal is to look at the rate and latency for accessing
BAR-mapped registers

cheers
luigi​




-- 
-+---
 Prof. Luigi RIZZO, ri...@iet.unipi.it  . Dip. di Ing. dell'Informazione
 http://www.iet.unipi.it/~luigi/. Universita` di Pisa
 TEL  +39-050-2217533   . via Diotisalvi 2
 Mobile   +39-338-6809875   . 56122 PISA (Italy)
-+---
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-04-01 Thread Dimitry Andric 
On 01 Apr 2016, at 00:44, Warner Losh  wrote:
> 
>> On Mar 31, 2016, at 4:34 PM, Bryan Drewery  wrote:
>> I didn't realize the ports compiler was defaulting /usr/local/include
>> into the search path now.  It does not have /usr/local/lib in the
>> default library path as far as I can tell.  It's also broken for its
>> -rpath (noted in its pkg-message).  So having a default
>> /usr/local/include path seems odd.
> 
> It has for a while now. It’s one of the maddening inconsistencies that abound 
> in this
> area. I took a poll a while ago and there seemed to be widespread support for 
> adding
> it to the base compiler.

This was the main reason /usr/local/include was *not* included in the
base compiler, otherwise it would unpredictably pick up headers in
/usr/local/include during builds.  You can never know which conflicting
headers a certain user has installed in /usr/local/include... :)


>> Adding -isystem /usr/include to fix this is probably possible but
>> there's a risk someone will remove it as redundant.  In this case I wish
>> /usr/include was first but I'm not sure what impact that would have on
>> consumers expecting /usr/local/include (and /usr/local/lib) overrides to
>> work, though they would need to pass a -L /usr/local/lib anyhow and
>> would likely be passing -I /usr/local/lib too.
> 
> /usr/include should be first. But it isn’t. That’s another inconsistency that 
> was found
> when we looked at /usr/local stuff. Someone recently added /usr/local/bin to 
> the path,
> if I recall correctly.

Isn't that a bit of a bikeshed?  I guess some people would just as well
prefer /usr/local/include to be first, just like some people prefer
/usr/local/bin before /usr/bin in their PATH.

In any case, if such paths are added to external compilers, we better
make sure almost everything in buildworld uses -nostdinc, and specifying
exactly the include directories we need, and no others.  Cumbersome, but
maybe for a good cause.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail