Re: bectl slow

[Kyle Evans]

On Mon, Feb 18, 2019 at 9:20 PM Graham Perrin  wrote:
>
> On 19/02/2019 03:05, Kyle Evans wrote:
> > I'd be interested in seeing what happens when you apply this diff:
> > https://people.freebsd.org/~kevans/bectl-perf.diff
>
>
> Thanks, I'll let you know.
>
> In the meantime: here are timings for creating then activating a boot
> environment.
>
> root@momh167-gjp4-8570p:~ # svn up /usr/src
> Updating '/usr/src':
> At revision 344270.
> root@momh167-gjp4-8570p:~ # date ; uptime ; uname -v ; time bectl create
> r344270
> Tue Feb 19 03:16:08 GMT 2019
>   3:16AM  up  2:41, 4 users, load averages: 1.27, 1.82, 1.59
> FreeBSD 13.0-CURRENT r344013 GENERIC-NODEBUG
> 0.000u 0.013s 1:05.83 0.0%  12+140k 22+0io 0pf+0w
> root@momh167-gjp4-8570p:~ # time bectl activate r344270
> successfully activated boot environment r344270
> 0.000u 0.018s 1:08.08 0.0%  24+280k 19+0io 0pf+0w
> root@momh167-gjp4-8570p:~ # exit
> logout
> grahamperrin@momh167-gjp4-8570p:~ % shutdown -r now
>

Oh, sorry, I missed the part where bectl create was also slow -- the
patch will likely reveal nothing interesting. How about things like
'zfs list' and 'zfs get all /ROOT/default'? Also slow?
___
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: bectl slow

[Graham Perrin]

On 19/02/2019 03:05, Kyle Evans wrote:

I'd be interested in seeing what happens when you apply this diff:
https://people.freebsd.org/~kevans/bectl-perf.diff



Thanks, I'll let you know.

In the meantime: here are timings for creating then activating a boot 
environment.


root@momh167-gjp4-8570p:~ # svn up /usr/src
Updating '/usr/src':
At revision 344270.
root@momh167-gjp4-8570p:~ # date ; uptime ; uname -v ; time bectl create 
r344270

Tue Feb 19 03:16:08 GMT 2019
 3:16AM  up  2:41, 4 users, load averages: 1.27, 1.82, 1.59
FreeBSD 13.0-CURRENT r344013 GENERIC-NODEBUG
0.000u 0.013s 1:05.83 0.0%  12+140k 22+0io 0pf+0w
root@momh167-gjp4-8570p:~ # time bectl activate r344270
successfully activated boot environment r344270
0.000u 0.018s 1:08.08 0.0%  24+280k 19+0io 0pf+0w
root@momh167-gjp4-8570p:~ # exit
logout
grahamperrin@momh167-gjp4-8570p:~ % shutdown -r now

___
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: bectl slow

[Kyle Evans]

On Mon, Feb 18, 2019 at 8:34 PM Graham Perrin  wrote:
>
> Preparing to update the OS, I created a new boot environment. Creation
> took a long time, subsequent bectl commands are extraordinarily slow.
>
> Whilst composing this e-mail I'm awaiting completion of a simple list.
>
> Any ideas?
>
> zpool status shows no problem. Last scrubbed 27th December, I'll begin a
> scrub after the current 'bectl list' command completes …
>
> 
>
> grahamperrin@momh167-gjp4-8570p:~ % su -
> Password:
> root@momh167-gjp4-8570p:~ # svn up /usr/src
> Updating '/usr/src':
> U/usr/src/lib/libmemstat/memstat_uma.c
> U/usr/src/lib/clang/libllvmminimal/Makefile
> U/usr/src/stand/common/part.c
> U/usr/src/stand/common/disk.c
> U/usr/src/stand/uboot/common/main.c
> U/usr/src/stand/uboot/lib/libuboot.h
> U/usr/src/stand/libsa/cd9660.c
> U/usr/src/stand/libsa/zfs/zfs.c
> U/usr/src/stand/lua/password.lua
> U/usr/src/stand/powerpc/uboot/Makefile
> U/usr/src/sys/arm/freescale/imx/imx6_snvs.c
> U/usr/src/sys/amd64/amd64/pmap.c
> U/usr/src/sys/amd64/sgx/sgx_linux.c
> U/usr/src/sys/dev/netmap/netmap_freebsd.c
> U/usr/src/sys/dev/netmap/netmap_kern.h
> U/usr/src/sys/conf/ldscript.riscv
> U/usr/src/sys/contrib/libnv/nvpair.c
> U/usr/src/sys/kern/sys_pipe.c
> U/usr/src/contrib/libc++/include/type_traits
> U/usr/src/usr.bin/kdump/kdump.c
> U /usr/src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_partition_tbl.c
> U/usr/src/usr.sbin/rpc.ypupdated/update.c
> U/usr/src/usr.sbin/bsdinstall/partedit/partedit_powerpc.c
> U/usr/src/etc/mtree/BSD.root.dist
> Updated to revision 344269.
> root@momh167-gjp4-8570p:~ # svn up /usr/src
> Updating '/usr/src':
> At revision 344269.
> root@momh167-gjp4-8570p:~ # bectl create r344269
> load: 0.64  cmd: bectl 33517 [fu_ans] 29.69r 0.00u 0.01s 0% 4460k
> load: 0.49  cmd: bectl 33517 [fu_ans] 53.59r 0.00u 0.01s 0% 4460k
> root@momh167-gjp4-8570p:~ # date ; uptime ; uname -v
> Tue Feb 19 01:46:46 GMT 2019
>   1:46AM  up  1:11, 4 users, load averages: 0.42, 0.57, 0.79
> FreeBSD 13.0-CURRENT r344013 GENERIC-NODEBUG
> root@momh167-gjp4-8570p:~ # time bectl list | sort
> load: 0.10  cmd: sort 33904 [piperd] 1145.34r 0.00u 0.00s 0% 2612k
> ^C^C
> load: 0.18  cmd: bectl 33903 [fu_ans] 1175.24r 0.01u 0.03s 0% 4740k
> ^Croot@momh167-gjp4-8570p:~ # date
> Tue Feb 19 02:07:07 GMT 2019
> root@momh167-gjp4-8570p:~ # time bectl list
> BEActive Mountpoint Space Created
> r344013   NR /  22.6G 2019-02-11 16:17
> r344231   -  -  3.81G 2019-02-17 16:38
> r343747   -  -  6.57G 2019-02-04 18:04
> r343883   -  -  6.90G 2019-02-07 23:11
> r342466   -  -  521M  2019-01-07 07:53
> r344269   -  -  392K  2019-02-19 01:42
> 20190131-0125 -  -  487M  2019-01-31 01:25
> default   -  -  2.16M 2018-12-22 05:01
>

I'd be interested in seeing what happens when you apply this diff:
https://people.freebsd.org/~kevans/bectl-perf.diff
___
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: bectl slow

[Graham Perrin]

On 19/02/2019 02:50, Adam wrote:
On Mon, Feb 18, 2019 at 8:35 PM Graham Perrin > wrote:


Preparing to update the OS, I created a new boot environment.
Creation
took a long time, subsequent bectl commands are extraordinarily slow.

Whilst composing this e-mail I'm awaiting completion of a simple list.

Any ideas?

zpool status shows no problem. Last scrubbed 27th December, I'll
begin a
scrub after the current 'bectl list' command completes …


What happens if you try it without fuse loaded?

--
Adam



root@momh167-gjp4-8570p:~ # kldunload fuse.ko
kldunload: can't unload file: Device busy

If it helps: fusefs-ext4fuse was amongst packages that were identified 
during a recent run of `pkg autoremove`. I recall running this before 
actually allowing removal:


pkg query %e jackit celt fdk-aac fusefs-ext4fuse luajit mbedtls

___
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: bectl slow

[Adam]

On Mon, Feb 18, 2019 at 8:35 PM Graham Perrin 
wrote:

> Preparing to update the OS, I created a new boot environment. Creation
> took a long time, subsequent bectl commands are extraordinarily slow.
>
> Whilst composing this e-mail I'm awaiting completion of a simple list.
>
> Any ideas?
>
> zpool status shows no problem. Last scrubbed 27th December, I'll begin a
> scrub after the current 'bectl list' command completes …
>

What happens if you try it without fuse loaded?

-- 
Adam
___
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"

bectl slow

[Graham Perrin]

Preparing to update the OS, I created a new boot environment. Creation 
took a long time, subsequent bectl commands are extraordinarily slow.


Whilst composing this e-mail I'm awaiting completion of a simple list.

Any ideas?

zpool status shows no problem. Last scrubbed 27th December, I'll begin a 
scrub after the current 'bectl list' command completes …




grahamperrin@momh167-gjp4-8570p:~ % su -
Password:
root@momh167-gjp4-8570p:~ # svn up /usr/src
Updating '/usr/src':
U    /usr/src/lib/libmemstat/memstat_uma.c
U    /usr/src/lib/clang/libllvmminimal/Makefile
U    /usr/src/stand/common/part.c
U    /usr/src/stand/common/disk.c
U    /usr/src/stand/uboot/common/main.c
U    /usr/src/stand/uboot/lib/libuboot.h
U    /usr/src/stand/libsa/cd9660.c
U    /usr/src/stand/libsa/zfs/zfs.c
U    /usr/src/stand/lua/password.lua
U    /usr/src/stand/powerpc/uboot/Makefile
U    /usr/src/sys/arm/freescale/imx/imx6_snvs.c
U    /usr/src/sys/amd64/amd64/pmap.c
U    /usr/src/sys/amd64/sgx/sgx_linux.c
U    /usr/src/sys/dev/netmap/netmap_freebsd.c
U    /usr/src/sys/dev/netmap/netmap_kern.h
U    /usr/src/sys/conf/ldscript.riscv
U    /usr/src/sys/contrib/libnv/nvpair.c
U    /usr/src/sys/kern/sys_pipe.c
U    /usr/src/contrib/libc++/include/type_traits
U    /usr/src/usr.bin/kdump/kdump.c
U /usr/src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_partition_tbl.c
U    /usr/src/usr.sbin/rpc.ypupdated/update.c
U    /usr/src/usr.sbin/bsdinstall/partedit/partedit_powerpc.c
U    /usr/src/etc/mtree/BSD.root.dist
Updated to revision 344269.
root@momh167-gjp4-8570p:~ # svn up /usr/src
Updating '/usr/src':
At revision 344269.
root@momh167-gjp4-8570p:~ # bectl create r344269
load: 0.64  cmd: bectl 33517 [fu_ans] 29.69r 0.00u 0.01s 0% 4460k
load: 0.49  cmd: bectl 33517 [fu_ans] 53.59r 0.00u 0.01s 0% 4460k
root@momh167-gjp4-8570p:~ # date ; uptime ; uname -v
Tue Feb 19 01:46:46 GMT 2019
 1:46AM  up  1:11, 4 users, load averages: 0.42, 0.57, 0.79
FreeBSD 13.0-CURRENT r344013 GENERIC-NODEBUG
root@momh167-gjp4-8570p:~ # time bectl list | sort
load: 0.10  cmd: sort 33904 [piperd] 1145.34r 0.00u 0.00s 0% 2612k
^C^C
load: 0.18  cmd: bectl 33903 [fu_ans] 1175.24r 0.01u 0.03s 0% 4740k
^Croot@momh167-gjp4-8570p:~ # date
Tue Feb 19 02:07:07 GMT 2019
root@momh167-gjp4-8570p:~ # time bectl list
BE    Active Mountpoint Space Created
r344013   NR /  22.6G 2019-02-11 16:17
r344231   -  -  3.81G 2019-02-17 16:38
r343747   -  -  6.57G 2019-02-04 18:04
r343883   -  -  6.90G 2019-02-07 23:11
r342466   -  -  521M  2019-01-07 07:53
r344269   -  -  392K  2019-02-19 01:42
20190131-0125 -  -  487M  2019-01-31 01:25
default   -  -  2.16M 2018-12-22 05:01

___
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: What is evdev and autoloading?

[Warner Losh]

On Mon, Feb 18, 2019 at 9:50 AM Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:

> On Mon, Feb 18, 2019 at 09:11:14AM -0700, Warner Losh wrote:
> >
> > You do know these constant complaints about people trying to make things
> > better is demoralizing and counter productive.
> >
>
> You do realize some of the emails are from frustrated users
> who are trying to make FreeBSD (see for example libm).
>

Yes. I get that. My frustration isn't with you, or your questions. I get
why you want to run -current. I'm sorry it's being painful for you.
Sometimes, -current is like that.

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: What is evdev and autoloading?

[Warner Losh]

On Mon, Feb 18, 2019 at 9:50 AM Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:

> > On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes <
> > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> >
> > > > On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote:
> > > > > > On 2/18/19 12:06 PM, Stefan Blachmann wrote:
> > > > > > > On 2/18/19, Vladimir Kondratyev 
> wrote:
> > > > > > >> On 2019-02-17 21:03, Steve Kargl wrote:
> > > > > > >>> Anyone have insight into what evdev is?
> > > > > > >> evdev.ko is a small in-kernel library that makes all your
> input
> > > events
> > > > > > >> like keyboard presses libinput-compatible.
> > > > > > >
> > > > > > > And libinput was created by the Freedesktop Wayland team to
> create
> > > > > > > pressure on OS people to make their systems Wayland-compatible.
> > > > > > >
> > > > > > >>> I do not need nor what these modules loaded.
> > > > > > >> I think removing "option EVDEV_SUPPORT" from your kernel
> config
> > > should
> > > > > > >> disable most of evdev.ko dependencies
> > > > > > >
> > > > > > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway,
> as
> > > well
> > > > > > > as libinput not be part of the standard packages?
> > > > > > >
> > > > > > > The Freedesktop Wayland team consists of people with the Kay
> > > Sievers
> > > > > > > mentality, which made Linus Torvalds ban his contributions.
> They do
> > > > > > > not care about the bugs they introduce, forcing others to
> clean up
> > > the
> > > > > > > mess they create.
> > > > > > >
> > > > > > > I'd be glad if FreeBSD would keep clean of following that
> Wayland
> > > fad...
> > > > > >
> > > > > > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to
> improve
> > > > > > input device handling in X and Wayland.  Not having it means
> that a
> > > lot
> > > > > > of input devices stop working, or work much worse.
> > > > > >
> > > > > > We in the FreeBSD Graphics Team are working very hard to improve
> the
> > > > > > FreeBSD Desktop experience, since it is an avenue to recruit new
> > > users,
> > > > > > and make current users use FreeBSD more.
> > > > >
> > > > > Sadly your execution on that seems to be missing the mark,
> > > > > telling people they have to go get a port now to get drm working
> > > > > because it could not be maintained in base, and then telling them,
> > > > > oh, you need this new code in base so that it is so much easier
> > > > > to use graphical stuff this way.
> > > > >
> > > > > These seem to be conflicting stories.
> > > > >
> > > > You are missing the point, one does not evolve as fast as the other,
> > > meaning
> > > > one can be maintained within usual freebsd lifecycle, the other
> cannot
> > > or it
> > > > becomes very painful.
> > >
> > > So to ditch our 5 years support model, kick the code out of the tree
> and
> > > make the users suffer?  The support model is suppose to be under
> review,
> > > and IMHO, if kicking functional code out of the base system is to make
> > > it possible to meet some support model we should defanitly take a very
> > > close look at that issue.
> > >
> > > The code has simply gone from being in base to a few git repositories
> > > which are probably going to rot every time a breaking ABI change occurs
> > > and we wend up with un happy users, un happy developers and bugmisters
> > > who have to close bogus bug reports.
> > >
> > > Have we really moved the state of the art forward by this action,
> simply
> > > in the name of "we could not suppor that code?"
> > >
> >
> > I don't know. I think the fact that drm2 doesn't support anything newer
> > than 5-year-old hardware is a pretty convincing evidence that the old way
> > is broken and doesn't work.
>
> But it DOES work, I am pretty sure we have 1000's of users on that 5 year
> old hardware that are totally happy with the in tree DRM2 that is in
> stable/12,
> and some of whom have ventured into head/13 are having issues with the
> "new" model (ie kmod broken by a base commit).


First off, current is current. Second, they have two different drm modules
to choose from. The drm-legacy stuff was broken by a commit to base, but
even if it had been in base, and connected to the build, it would have been
broken. kib would have fixed the compile issue (which we did fix in github
almost as soon as it happend). However, the semantic issue he wouldn't have
seen because he wouldn't have actually tested the setup that's broken
because he doesn't have it.

So please stop saying it does work. It does not work. It was silently
broken by kib's changes. The compile issue is a red herring.  You'd be
fighting the same issue in current if it was connected to the build. It's
literally the same code.


> I know that there is wip
> to get CI coverage for that, but wip is wip, and we need to start changing
> the cart horse driver order we keep doing and get things right.  Port
> up and working, with CI testing *before* we go remove kmod'ed code from
> base would be a 

Re: What is evdev and autoloading?

[Michael Gmelin]

> On 18. Feb 2019, at 23:54, Mark Linimon  wrote:
> 
>> On Mon, Feb 18, 2019 at 08:50:27AM -0800, Rodney W. Grimes wrote:
>> I think one serious problem here is the summary dismissal of things
>> simply on the "5 year old" basis.
> 
> IIUC the graphics changes are being forced upon FreeBSD by external
> projects (mainly Linux-based) that are making huge architectural changes
> that rely more and more on features from newer hardware.
> 
> If our upstreams aren't willing to do the work to keep from violating
> POLA on older hardware, IMHO it's an awful lot to ask of our already
> thinly stretched graphics volunteers to provide it in their stead.
> 
> w/rt graphics, we are at far more danger of being left further and
> further behind on modern hardware than we are at risk of losing users
> on older hardware here.
> 
> Again all IMHO.
> 
> disclaimer: I don't use any fancy graphics stuff, so (as the old folks
> say around here)

I’m very happy (and grateful) that 2018 was the first year in over a decade I 
was able to run FreeBSD on a state of the art laptop with all the features that 
are essential to me working - which included decent touchpad support provided 
through evdev+libinput.

-m


___
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: What is evdev and autoloading?

[Mark Linimon]

On Mon, Feb 18, 2019 at 08:50:27AM -0800, Rodney W. Grimes wrote:
> I think one serious problem here is the summary dismissal of things
> simply on the "5 year old" basis.

IIUC the graphics changes are being forced upon FreeBSD by external
projects (mainly Linux-based) that are making huge architectural changes
that rely more and more on features from newer hardware.

If our upstreams aren't willing to do the work to keep from violating
POLA on older hardware, IMHO it's an awful lot to ask of our already
thinly stretched graphics volunteers to provide it in their stead.

w/rt graphics, we are at far more danger of being left further and
further behind on modern hardware than we are at risk of losing users
on older hardware here.

Again all IMHO.

disclaimer: I don't use any fancy graphics stuff, so (as the old folks
say around here) "I have no dog in this hunt".

mcl
___
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: poudriere: 12-STABLE install fails after r344230

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Mon, 18 Feb 2019 08:06:54 +0100
"O. Hartmann"  schrieb:

> On Sun, 17 Feb 2019 19:07:53 +0100
> "O. Hartmann"  wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > Hello,
> > 
> > after the bump of 12-STABE to 1200503 I'm unable to update AMD64 poudriere
> > jails's to this version anymore! Now I run on every box into this error:
> > 
> > [...]
> > 
> > install -N /pool/sources/12-STABLE/src/etc  -C -o root -g wheel -m 444
> > libnandfs.a /pool/poudriere/jails/12-amd64/usr/lib/ --- _INCSINS ---
> > install -N /pool/sources/12-STABLE/src/etc  -C -o root -g wheel -m 444
> > libnandfs.h /pool/poudriere/jails/12-amd64/usr/include/ --- _libinstall ---
> > install: libnandfs.a: No such file or directory
> > *** [_libinstall] Error code 71
> > 
> > make[5]: stopped in /pool/sources/12-STABLE/src/lib/libnandfs
> > 
> > For arm64.aarch64 jails with the same build environment this error doesn't
> > show up! The base host is running CURRENT.
> >  
> > What the ... has this libnandfs.a to do?
> > 
> > Since I build 12-STABLE on CURRENT, I use sources
> > at  /pool/sources/12-STABLE/src and I also
> > utilize /usr/local/etc/poudriere.d/12-amd64-poudriere.conf with one line
> > 
> > export  MAKEOBJDIRPREFIX=/pool/sources/12-STABLE/obj/
> > 
> > to reflect the build tree.
> > 
> > This worked prior to 12-STABLE r344234, it still worls when building and
> > installing for arm64.aarch64 (same host, same CURRENT, same 12-STABLE
> > revision).
> > 
> > How to fix this?
> > 
> > Thanks in advance,
> > 
> > oh
> >   
> [...]
> 
> It seems that the issue occurs on CURRENT. Boxes running 12-STABLE (r344158) 
> or
> 12.0-RELENG (r344247) do not show the problem shown above.
> ___
> 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"

I started again on recent CURRENT (FreeBSD 13.0-CURRENT #190 r344259: Mon Feb 
18 17:48:28 CET
2019 amd64). The sources are located at 

/pool/source/12-STABLE/src

and /usr/local/etc/poudriere.d/poudriere.conf has

export  MAKEOBJDIRPREFIX=/pool/sources/12-STABLE/obj/

and doing a fresh start, /pool/sources/12-STABLE/obj and its subtrees has been 
deleted.

The name of my 12-STABLE jail is 12-amd64 and therefore, I build the world of 
that jail
by myself from sources located in /pool/sources/12-STABLE/src and build by 
src.conf common to
poudriere and the build process (to keep them in sync):

/usr/local/etc/poudriere.d/12-amd64-src.conf:

[...]
WITH_CLANG_EXTRAS=  YES
WITH_LLDB=  YES
#
#WITH_BSD_GREP= YES
#
#WITH_OFED_EXTRA=YES
#WITH_NAND=  YES
#WITH_CTF=  YES
#
#WITH_SVN=   YES
#
# Enable building openldap support for kerberos.
#WITH_OPENLDAP= YES
#
#WITH_SORT_THREADS=  YES
#
#WITH_EXTRA_TCP_STACKS= YES
#
#WITH_ZONEINFO_LEAPSECONDS_SUPPORT=  YES
#
MALLOC_PRODUCTION=  YES
#
WITHOUT_ASSERT_DEBUG=   YES
#
WITHOUT_DEBUG_FILES=YES
#
WITHOUT_TESTS=  YES
#
WITHOUT_PROFILE=YES
#
#WITHOUT_REPRODUCIBLE_BUILD= YES
#
#  mitigation for CVE-2017-5715 in the kernel build
#WITH_KERNEL_RETPOLINE= YES
[...]

I use those configs also for PKGbase repos, for which the poudriere packages 
should be built.

Now, with a almost vanilla setup, poudriere runs into weird erros different 
from the initial
reportd; first error now occuring see below;

I'm loosing hair over this; installing  poudriere jails from network/internet 
resources is no
option in the isolated environment I have to build things, so I felt really 
comfortable having
such a great opportunity of building my own bindaries from sources for repos 
and poudriere
jails from the very same source. Obviously, this is highly unstable.


Is this considered a bug or is it in general unsupported and "worked by 
accident"?

Regards,

oh
[...]
- --- realinstall_subdir_usr.sbin ---
- --- installdirs-FILESDIR ---
- --- realinstall_subdir_usr.bin ---
- --- _proginstall ---
install -N /pool/sources/12-STABLE/src/etc  -s -o root -g wheel -m 555
bugpoint /pool/poudriere/jails/12-amd64/usr/bin/bugpoint install: bugpoint: No 
such file or
directory 
*** [_proginstall] Error code 71

make[6]: stopped in /pool/sources/12-STABLE/src/usr.bin/clang/bugpoint
1 error

make[6]: stopped in /pool/sources/12-STABLE/src/usr.bin/clang/bugpoint

- --- realinstall_subdir_usr.sbin ---
installing DIRS FILESDIR
install -N /pool/sources/12-STABLE/src/etc  -d -m 0755 -o root  -g
wheel  /pool/poudriere/jails/12-amd64/usr/libexec/bsdconfig/080.console/include 
---
_FILESINS_messages.subr --- --- realinstall_subdir_usr.bin ---
*** [realinstall_subdir_usr.bin/clang/bugpoint] Error code 2

make[5]: stopped in /pool/sources/12-STABLE/src/usr.bin/clang
1 error

make[5]: stopped in 

Re: What is evdev and autoloading?

[Wojciech Puchar]

motivated me to do this:

1) my observation that many developers at conferences and online were using 
macOS as their primary desktop environment.  when comparing this to the 
OpenBSD and Linux community I felt pretty embarrassed, but it did explain the 
stagnant nature of our graphics subsystem.  people seemed afraid to touch 
things due the brittle nature of its hardware support.


2) i was in need to an *affordable* machine with a warranty. fortunately 
there are many affordable laptops at staples, best-buy and amazon - but they 
were all post haswell systems, rendering them basically useless from a 
FreeBSD perspective.


I've bought recently (like half year ago) cheapest laptop available. 
Everything supported with FreeBSD out of the box, except little problem 
with sound but


dev.hdac.0.polling=1

made it work.

What a problem? Even lowest end today computer is really high end for 
normal programs.

___
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: What is evdev and autoloading?

[Pete Wright]

On 2/17/19 6:48 PM, Ian Lepore wrote:


That manpage you found online is in section 4x. It probably gets
installed along with the xf86-input-evdev package.
yes - unfortunately that seems to be the only form of man page that 
exists on the linux side as well.  did a quick search through the linux 
source and there is unsurprisingly a lack of coherent documentation for 
the evdev driver there (there is plenty online - wikipedia is a decent 
starting place).


getting a man page is a pretty high priority and should hopefully get 
sorted out before 12.1-RELEASE is ready...so the system works? lol


-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: What is evdev and autoloading?

[A. Wilcox]

On 02/18/19 10:50, Rodney W. Grimes wrote:
>> On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes <
>> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
>>
 On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote:
>> On 2/18/19 12:06 PM, Stefan Blachmann wrote:
>>> On 2/18/19, Vladimir Kondratyev  wrote:
 On 2019-02-17 21:03, Steve Kargl wrote:
> Anyone have insight into what evdev is?
 evdev.ko is a small in-kernel library that makes all your input
>>> events
 like keyboard presses libinput-compatible.


That's... wrong.

evdev has nothing to do with libinput.  Rather, it can be used by
libinput, but I never once used libinput on FreeBSD/X11.  I used
xf86-input-evdev.

evdev is a generic event device subsystem originated in the Linux kernel.


> But it DOES work, I am pretty sure we have 1000's of users on that 5 year
> old hardware that are totally happy with the intree DRM2 that is in stable/12,
> and some of whom have ventured into head/13 are having issues with the
> "new" model (ie kmod broken by a base commit).
> 
> I think one serious problem here is the summary dismissal of things
> simply on the "5 year old" basis.  Not everyone, and infact few now
> a days other than corporate buyers, can afford new hardware, 
> giving the minimal performance increase in systems over the last 5
> years the cost/benifit factor of a new computer is just too low.


That's the primary reason I don't focus on FreeBSD any more, and the
primary reason when I have sudden time crunches, FreeBSD stuff is the
first to go out the window.

It's not that I don't like FreeBSD any more, it's that it just doesn't
fit in with my ideas on how a system project should be run, or how it
should prioritise.  And that isn't really a comment on FreeBSD, nor me,
it's just a statement.  Everyone's different.

Perhaps all the people who are upset at FreeBSD becoming the next OS X
(you must have hardware *this* *new* to run!) should start putting more
effort in to keeping the old hardware alive and working in the processes
defined by FreeBSD.  Make proposals, participate and communicate on MLs
(instead of just complain), etc.

This is all just observations I've made over the last few months of
reading -current and not really contributing much.  Apologies if I'm off
the mark on any of this.

Best to you and yours,
--arw

-- 
A. Wilcox (awilfox)
Open-source programmer (C, C++, Python)
https://code.foxkit.us/u/awilfox/



signature.asc
Description: OpenPGP digital signature

Re: What is evdev and autoloading?

[Pete Wright]

On 2/18/19 8:50 AM, Rodney W. Grimes wrote:

On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes <

I don't know. I think the fact that drm2 doesn't support anything newer
than 5-year-old hardware is a pretty convincing evidence that the old way
is broken and doesn't work.

But it DOES work, I am pretty sure we have 1000's of users on that 5 year
old hardware that are totally happy with the intree DRM2 that is in stable/12,
and some of whom have ventured into head/13 are having issues with thete a
"new" model (ie kmod broken by a base commit).  I know that there is wip
to get CI coverage for that, but wip is wip, and we need to start changing
the cart horse driver order we keep doing and get things right.  Port
up and working, with CI testing *before* we go remove kmod'ed code from
base would be a much more appropriate path.

I think one serious problem here is the summary dismissal of things
simply on the "5 year old" basis.  Not everyone, and infact few now
a days other than corporate buyers, can afford new hardware,
giving the minimal performance increase in systems over the last 5
years the cost/benifit factor of a new computer is just too low.
I've put a lot of effort helping test and document how to get a usable 
desktop environment on a modern laptop.  there were two issues which 
motivated me to do this:


1) my observation that many developers at conferences and online were 
using macOS as their primary desktop environment.  when comparing this 
to the OpenBSD and Linux community I felt pretty embarrassed, but it did 
explain the stagnant nature of our graphics subsystem.  people seemed 
afraid to touch things due the brittle nature of its hardware support.


2) i was in need to an *affordable* machine with a warranty. fortunately 
there are many affordable laptops at staples, best-buy and amazon - but 
they were all post haswell systems, rendering them basically useless 
from a FreeBSD perspective.


after trying to get traction to update the in-tree drm subsystem i was 
lucky enough to sync up with the graphics team which was working on 
syncing things up with modern hardware support.  because of that i'm now 
able to get my small startup pretty much all on board with FreeBSD.  i 
use it on my workstations as well as on or server infrastructure 
(physical and AWS).  i would consider this a success for our community 
as it's opened up the eyes to a whole new generation of devs to FreeBSD.


one thing missing from all of these arguments is real data.  how many 
people are on haswell era hardware?  i can tell from my experience the 
past several years the number of people who have post-haswell gear seem 
to be more numerous, or at least more vocal (and frankly easier to work 
with while squashing bugs).


i can also say that personally it would be great to improve support for 
systems requiring drm2 - but that gear is hard to come by, so we are 
really dependent on helpful collaboration from those who are being effected.



-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: What is evdev and autoloading?

[Johannes Lundberg]

On 2/18/19 3:12 PM, Rodney W. Grimes wrote:
>> On 2/18/19 12:06 PM, Stefan Blachmann wrote:
>>> On 2/18/19, Vladimir Kondratyev  wrote:
 On 2019-02-17 21:03, Steve Kargl wrote:
> Anyone have insight into what evdev is?
 evdev.ko is a small in-kernel library that makes all your input events
 like keyboard presses libinput-compatible.
>>> And libinput was created by the Freedesktop Wayland team to create
>>> pressure on OS people to make their systems Wayland-compatible.
>>>
> I do not need nor what these modules loaded.
 I think removing "option EVDEV_SUPPORT" from your kernel config should
 disable most of evdev.ko dependencies
>>> Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well
>>> as libinput not be part of the standard packages?
>>>
>>> The Freedesktop Wayland team consists of people with the Kay Sievers
>>> mentality, which made Linus Torvalds ban his contributions. They do
>>> not care about the bugs they introduce, forcing others to clean up the
>>> mess they create.
>>>
>>> I'd be glad if FreeBSD would keep clean of following that Wayland fad...
>> EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve 
>> input device handling in X and Wayland.  Not having it means that a lot 
>> of input devices stop working, or work much worse.
>>
>> We in the FreeBSD Graphics Team are working very hard to improve the 
>> FreeBSD Desktop experience, since it is an avenue to recruit new users, 
>> and make current users use FreeBSD more.
> Sadly your execution on that seems to be missing the mark,
> telling people they have to go get a port now to get drm working
> because it could not be maintained in base, and then telling them,
> oh, you need this new code in base so that it is so much easier
> to use graphical stuff this way.
>
> These seem to be conflicting stories.

You don't need evdev or libinput to have a functional desktop with a
3-button mouse but some modern desktop environments require it. Why
should we not include the large group of people who want to run a modern
desktop? Including more users does not mean excluding anyone in this case.


>
>> Evdev and libinput is used by both Wayland and xorg.  You are free to 
>> use either one.
> And sadly now must take action when no action was required before
> when using neither.

Take what action? If you don't need it, just don't use it. If you don't
want change, stay on older release. If you are a purist and want to
remove everything in the kernel you don't use, you probably already have
your custom kernel config, and you probably are a minority. Consider the
well-being, progress and future of the project and the community at
large instead of your ego.


>

___
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: What is evdev and autoloading?

[Steve Kargl]

On Mon, Feb 18, 2019 at 09:35:26AM -0700, Warner Losh wrote:
> On Sun, Feb 17, 2019 at 3:52 PM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
> 
> > Anyone have insight into what evdev is?  There appears to
> > be no manual page.  When I reboot a system with custom
> > kernel, the system is autoloading evdev.ko, uhid.ko, and
> > wmt.ko.  I do not need nor what these modules loaded.
> > How does one prevent this autoloading?
> >
> 
> 
> This thread has taken a weird turn, so I went back to the original post.
> 
> When do these things get loaded? Is it when you start up X11? Or is it
> being brought in by devmatch? If it is being brought in by x11, there's
> likely an x11 config that you'll need to avoid them (but that will reduce
> functionality). If it is devmatch, then you can add them to the black list
> and have them not load them.
> 

I think it is devmatch (or at least devd.conf related).
I have a wireless USB logitch mouse.  If I unplug the dongle
from its port and reboot, evdev.ko, uhid.ko, and wmt.ko do
not get loaded.  When I plug in the dongle, the 3 get loaded.
I can kldunload wmt and evdev, but as soon as the mouse is
moved both are reloaded.

ums(4) does not mention any of these devices as a requirement.
wmt(4) says it only works for touchscreen.  This laptop pre-dates
touchscreens, so loading the module is simply wasteful.  There
is no evdev(4), so can't determine what it is or does.

-- 
Steve
___
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: What is evdev and autoloading?

[Steve Kargl]

On Mon, Feb 18, 2019 at 09:58:14AM -0700, Ian Lepore wrote:
> On Mon, 2019-02-18 at 08:50 -0800, Steve Kargl wrote:
> > On Mon, Feb 18, 2019 at 09:11:14AM -0700, Warner Losh wrote:
> > > 
> > > You do know these constant complaints about people trying to make
> > > things
> > > better is demoralizing and counter productive.
> > > 
> > 
> > You do realize some of the emails are from frustrated users
> > who are trying to make FreeBSD (see for example libm).  
> > 
> 
> And do you realize that you've trimmed away all the context so that now
> it looks like Warner was talking to you, when in fact he was replying
> to Rod? I sure hope that was an accident.
> 

Thanks for your considered input.  It has been noted.

-- 
Steve
___
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: What is evdev and autoloading?

[Ian Lepore]

On Mon, 2019-02-18 at 08:50 -0800, Steve Kargl wrote:
> On Mon, Feb 18, 2019 at 09:11:14AM -0700, Warner Losh wrote:
> > 
> > You do know these constant complaints about people trying to make
> > things
> > better is demoralizing and counter productive.
> > 
> 
> You do realize some of the emails are from frustrated users
> who are trying to make FreeBSD (see for example libm).  
> 

And do you realize that you've trimmed away all the context so that now
it looks like Warner was talking to you, when in fact he was replying
to Rod? I sure hope that was an accident.

-- Ian

___
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: What is evdev and autoloading?

[Steve Kargl]

On Mon, Feb 18, 2019 at 09:11:14AM -0700, Warner Losh wrote:
> 
> You do know these constant complaints about people trying to make things
> better is demoralizing and counter productive.
> 

You do realize some of the emails are from frustrated users
who are trying to make FreeBSD (see for example libm).  

-- 
Steve
___
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: What is evdev and autoloading?

[Rodney W. Grimes]

> On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes <
> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> 
> > > On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote:
> > > > > On 2/18/19 12:06 PM, Stefan Blachmann wrote:
> > > > > > On 2/18/19, Vladimir Kondratyev  wrote:
> > > > > >> On 2019-02-17 21:03, Steve Kargl wrote:
> > > > > >>> Anyone have insight into what evdev is?
> > > > > >> evdev.ko is a small in-kernel library that makes all your input
> > events
> > > > > >> like keyboard presses libinput-compatible.
> > > > > >
> > > > > > And libinput was created by the Freedesktop Wayland team to create
> > > > > > pressure on OS people to make their systems Wayland-compatible.
> > > > > >
> > > > > >>> I do not need nor what these modules loaded.
> > > > > >> I think removing "option EVDEV_SUPPORT" from your kernel config
> > should
> > > > > >> disable most of evdev.ko dependencies
> > > > > >
> > > > > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as
> > well
> > > > > > as libinput not be part of the standard packages?
> > > > > >
> > > > > > The Freedesktop Wayland team consists of people with the Kay
> > Sievers
> > > > > > mentality, which made Linus Torvalds ban his contributions. They do
> > > > > > not care about the bugs they introduce, forcing others to clean up
> > the
> > > > > > mess they create.
> > > > > >
> > > > > > I'd be glad if FreeBSD would keep clean of following that Wayland
> > fad...
> > > > >
> > > > > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve
> > > > > input device handling in X and Wayland.  Not having it means that a
> > lot
> > > > > of input devices stop working, or work much worse.
> > > > >
> > > > > We in the FreeBSD Graphics Team are working very hard to improve the
> > > > > FreeBSD Desktop experience, since it is an avenue to recruit new
> > users,
> > > > > and make current users use FreeBSD more.
> > > >
> > > > Sadly your execution on that seems to be missing the mark,
> > > > telling people they have to go get a port now to get drm working
> > > > because it could not be maintained in base, and then telling them,
> > > > oh, you need this new code in base so that it is so much easier
> > > > to use graphical stuff this way.
> > > >
> > > > These seem to be conflicting stories.
> > > >
> > > You are missing the point, one does not evolve as fast as the other,
> > meaning
> > > one can be maintained within usual freebsd lifecycle, the other cannot
> > or it
> > > becomes very painful.
> >
> > So to ditch our 5 years support model, kick the code out of the tree and
> > make the users suffer?  The support model is suppose to be under review,
> > and IMHO, if kicking functional code out of the base system is to make
> > it possible to meet some support model we should defanitly take a very
> > close look at that issue.
> >
> > The code has simply gone from being in base to a few git repositories
> > which are probably going to rot every time a breaking ABI change occurs
> > and we wend up with un happy users, un happy developers and bugmisters
> > who have to close bogus bug reports.
> >
> > Have we really moved the state of the art forward by this action, simply
> > in the name of "we could not suppor that code?"
> >
> 
> I don't know. I think the fact that drm2 doesn't support anything newer
> than 5-year-old hardware is a pretty convincing evidence that the old way
> is broken and doesn't work.

But it DOES work, I am pretty sure we have 1000's of users on that 5 year
old hardware that are totally happy with the intree DRM2 that is in stable/12,
and some of whom have ventured into head/13 are having issues with the
"new" model (ie kmod broken by a base commit).  I know that there is wip
to get CI coverage for that, but wip is wip, and we need to start changing
the cart horse driver order we keep doing and get things right.  Port
up and working, with CI testing *before* we go remove kmod'ed code from
base would be a much more appropriate path.

I think one serious problem here is the summary dismissal of things
simply on the "5 year old" basis.  Not everyone, and infact few now
a days other than corporate buyers, can afford new hardware, 
giving the minimal performance increase in systems over the last 5
years the cost/benifit factor of a new computer is just too low.

One of the long standing features of running a BSD is that it could
stretch very good life out of hardware, and imho it would be in our
best interest to try and keep that.   And we do in most aspects,
though recently in some hardware testing OpenBSD beat us in several
cases of "just booted and worked" on several pieces of hardware
that came accross my bench for data recovery.  FreeBSD would not
even boot, or paniced early in the kernel :-(  None of these systems
was older than a P4.

> Warner

-- 
Rod Grimes rgri...@freebsd.org
___

Re: What is evdev and autoloading?

[Steve Kargl]

On Mon, Feb 18, 2019 at 09:32:52AM -0700, Warner Losh wrote:
> On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes <
> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> 
> > So to ditch our 5 years support model, kick the code out of the tree and
> > make the users suffer?  The support model is suppose to be under review,
> > and IMHO, if kicking functional code out of the base system is to make
> > it possible to meet some support model we should defanitly take a very
> > close look at that issue.
> >
> > The code has simply gone from being in base to a few git repositories
> > which are probably going to rot every time a breaking ABI change occurs
> > and we wend up with un happy users, un happy developers and bugmisters
> > who have to close bogus bug reports.
> >
> > Have we really moved the state of the art forward by this action, simply
> > in the name of "we could not suppor that code?"
> >
> 
> I don't know. I think the fact that drm2 doesn't support anything newer
> than 5-year-old hardware is a pretty convincing evidence that the old way
> is broken and doesn't work.
> 

When drm2 was unhooked from the build, it was working fine.
drm2 was unhooked because it supposedly interferred with
the drm-stable-kmod and drm-current-kmod ports. 

-- 
Steve
___
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: What is evdev and autoloading?

[Steve Kargl]

On Mon, Feb 18, 2019 at 04:56:57PM +0100, Baptiste Daroussin wrote:
> On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote:
> > 
> > Sadly your execution on that seems to be missing the mark,
> > telling people they have to go get a port now to get drm working
> > because it could not be maintained in base, and then telling them,
> > oh, you need this new code in base so that it is so much easier
> > to use graphical stuff this way.
> > 
> > These seem to be conflicting stories.
> > 
> You are missing the point, one does not evolve as fast as the other, meaning
> one can be maintained within usual freebsd lifecycle, the other cannot or it
> becomes very painful.
> 

And you seem to be missing the point.  I'm now in week two of
trying to figure out why drm-legacy-kmod no longer works, and
suddenly new devices are popping up which are not configured
in my kernel.

I have deleted all ports.  I have delete /usr/src and /usr/obj.
I used svn to pull a -r "{2019-01-01}" /usr/src.  That builds
and works fine.  I then build the minimum ports needs to install
drm-legacy-kmod and xorg.  I can fire a fvwm2 desktop.  I'm now
up to -r "{2019-01-28}".  Yes, bi-section be date.  It takes 6-7
hours to rebuild world and kernel and another hour or 2 for the
minimum set of ports.

PS: It still does answer why there isn't a manual page for evdev.

-- 
steve
___
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: What is evdev and autoloading?

[Warner Losh]

On Sun, Feb 17, 2019 at 3:52 PM Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:

> Anyone have insight into what evdev is?  There appears to
> be no manual page.  When I reboot a system with custom
> kernel, the system is autoloading evdev.ko, uhid.ko, and
> wmt.ko.  I do not need nor what these modules loaded.
> How does one prevent this autoloading?
>

Hi Steve,

This thread has taken a weird turn, so I went back to the original post.

When do these things get loaded? Is it when you start up X11? Or is it
being brought in by devmatch? If it is being brought in by x11, there's
likely an x11 config that you'll need to avoid them (but that will reduce
functionality). If it is devmatch, then you can add them to the black list
and have them not load them.

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: What is evdev and autoloading?

[Warner Losh]

On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:

> > On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote:
> > > > On 2/18/19 12:06 PM, Stefan Blachmann wrote:
> > > > > On 2/18/19, Vladimir Kondratyev  wrote:
> > > > >> On 2019-02-17 21:03, Steve Kargl wrote:
> > > > >>> Anyone have insight into what evdev is?
> > > > >> evdev.ko is a small in-kernel library that makes all your input
> events
> > > > >> like keyboard presses libinput-compatible.
> > > > >
> > > > > And libinput was created by the Freedesktop Wayland team to create
> > > > > pressure on OS people to make their systems Wayland-compatible.
> > > > >
> > > > >>> I do not need nor what these modules loaded.
> > > > >> I think removing "option EVDEV_SUPPORT" from your kernel config
> should
> > > > >> disable most of evdev.ko dependencies
> > > > >
> > > > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as
> well
> > > > > as libinput not be part of the standard packages?
> > > > >
> > > > > The Freedesktop Wayland team consists of people with the Kay
> Sievers
> > > > > mentality, which made Linus Torvalds ban his contributions. They do
> > > > > not care about the bugs they introduce, forcing others to clean up
> the
> > > > > mess they create.
> > > > >
> > > > > I'd be glad if FreeBSD would keep clean of following that Wayland
> fad...
> > > >
> > > > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve
> > > > input device handling in X and Wayland.  Not having it means that a
> lot
> > > > of input devices stop working, or work much worse.
> > > >
> > > > We in the FreeBSD Graphics Team are working very hard to improve the
> > > > FreeBSD Desktop experience, since it is an avenue to recruit new
> users,
> > > > and make current users use FreeBSD more.
> > >
> > > Sadly your execution on that seems to be missing the mark,
> > > telling people they have to go get a port now to get drm working
> > > because it could not be maintained in base, and then telling them,
> > > oh, you need this new code in base so that it is so much easier
> > > to use graphical stuff this way.
> > >
> > > These seem to be conflicting stories.
> > >
> > You are missing the point, one does not evolve as fast as the other,
> meaning
> > one can be maintained within usual freebsd lifecycle, the other cannot
> or it
> > becomes very painful.
>
> So to ditch our 5 years support model, kick the code out of the tree and
> make the users suffer?  The support model is suppose to be under review,
> and IMHO, if kicking functional code out of the base system is to make
> it possible to meet some support model we should defanitly take a very
> close look at that issue.
>
> The code has simply gone from being in base to a few git repositories
> which are probably going to rot every time a breaking ABI change occurs
> and we wend up with un happy users, un happy developers and bugmisters
> who have to close bogus bug reports.
>
> Have we really moved the state of the art forward by this action, simply
> in the name of "we could not suppor that code?"
>

I don't know. I think the fact that drm2 doesn't support anything newer
than 5-year-old hardware is a pretty convincing evidence that the old way
is broken and doesn't work.

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: What is evdev and autoloading?

[Rodney W. Grimes]

> On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote:
> > > On 2/18/19 12:06 PM, Stefan Blachmann wrote:
> > > > On 2/18/19, Vladimir Kondratyev  wrote:
> > > >> On 2019-02-17 21:03, Steve Kargl wrote:
> > > >>> Anyone have insight into what evdev is?
> > > >> evdev.ko is a small in-kernel library that makes all your input events
> > > >> like keyboard presses libinput-compatible.
> > > > 
> > > > And libinput was created by the Freedesktop Wayland team to create
> > > > pressure on OS people to make their systems Wayland-compatible.
> > > > 
> > > >>> I do not need nor what these modules loaded.
> > > >> I think removing "option EVDEV_SUPPORT" from your kernel config should
> > > >> disable most of evdev.ko dependencies
> > > > 
> > > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well
> > > > as libinput not be part of the standard packages?
> > > > 
> > > > The Freedesktop Wayland team consists of people with the Kay Sievers
> > > > mentality, which made Linus Torvalds ban his contributions. They do
> > > > not care about the bugs they introduce, forcing others to clean up the
> > > > mess they create.
> > > > 
> > > > I'd be glad if FreeBSD would keep clean of following that Wayland fad...
> > > 
> > > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve 
> > > input device handling in X and Wayland.  Not having it means that a lot 
> > > of input devices stop working, or work much worse.
> > > 
> > > We in the FreeBSD Graphics Team are working very hard to improve the 
> > > FreeBSD Desktop experience, since it is an avenue to recruit new users, 
> > > and make current users use FreeBSD more.
> > 
> > Sadly your execution on that seems to be missing the mark,
> > telling people they have to go get a port now to get drm working
> > because it could not be maintained in base, and then telling them,
> > oh, you need this new code in base so that it is so much easier
> > to use graphical stuff this way.
> > 
> > These seem to be conflicting stories.
> > 
> You are missing the point, one does not evolve as fast as the other, meaning
> one can be maintained within usual freebsd lifecycle, the other cannot or it
> becomes very painful.

So to ditch our 5 years support model, kick the code out of the tree and
make the users suffer?  The support model is suppose to be under review,
and IMHO, if kicking functional code out of the base system is to make
it possible to meet some support model we should defanitly take a very
close look at that issue.

The code has simply gone from being in base to a few git repositories
which are probably going to rot every time a breaking ABI change occurs
and we wend up with un happy users, un happy developers and bugmisters
who have to close bogus bug reports.

Have we really moved the state of the art forward by this action, simply
in the name of "we could not suppor that code?"

-- 
Rod Grimes rgri...@freebsd.org
___
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: What is evdev and autoloading?

[Warner Losh]

On Mon, Feb 18, 2019 at 8:33 AM Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:

> > On 2/18/19 12:06 PM, Stefan Blachmann wrote:
> > > On 2/18/19, Vladimir Kondratyev  wrote:
> > >> On 2019-02-17 21:03, Steve Kargl wrote:
> > >>> Anyone have insight into what evdev is?
> > >> evdev.ko is a small in-kernel library that makes all your input events
> > >> like keyboard presses libinput-compatible.
> > >
> > > And libinput was created by the Freedesktop Wayland team to create
> > > pressure on OS people to make their systems Wayland-compatible.
> > >
> > >>> I do not need nor what these modules loaded.
> > >> I think removing "option EVDEV_SUPPORT" from your kernel config should
> > >> disable most of evdev.ko dependencies
> > >
> > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well
> > > as libinput not be part of the standard packages?
> > >
> > > The Freedesktop Wayland team consists of people with the Kay Sievers
> > > mentality, which made Linus Torvalds ban his contributions. They do
> > > not care about the bugs they introduce, forcing others to clean up the
> > > mess they create.
> > >
> > > I'd be glad if FreeBSD would keep clean of following that Wayland
> fad...
> >
> > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve
> > input device handling in X and Wayland.  Not having it means that a lot
> > of input devices stop working, or work much worse.
> >
> > We in the FreeBSD Graphics Team are working very hard to improve the
> > FreeBSD Desktop experience, since it is an avenue to recruit new users,
> > and make current users use FreeBSD more.
>
> Sadly your execution on that seems to be missing the mark,
> telling people they have to go get a port now to get drm working
> because it could not be maintained in base, and then telling them,
> oh, you need this new code in base so that it is so much easier
> to use graphical stuff this way.
>

The drm stuff in the tree didn't support new hardware. And the in-tree
rules made it impossible to import the GPL'd graphics drivers. And the
in-tree code was abandonware that worked only by accident.


> These seem to be conflicting stories.
>

You do know these constant complaints about people trying to make things
better is demoralizing and counter productive.

>
> > Evdev and libinput is used by both Wayland and xorg.  You are free to
> > use either one.
>
> And sadly now must take action when no action was required before
> when using neither.
>

Oh for foxs sake. We have so much stuff in the GENERIC kernel today that
this complaint rings hallow. How many desktop users benefit from
TCP_OFFLOAD? How many people SCTP? How many people are using ahc, ahd,
siis, mvs, ata, hptiop, esp, trm, amr, ciss, twa, mfi, cbb, pccard,
cardbus, de, le, ti, ae, hme, cas, nge, sf, tl, tx, wb, all the sound
drivers, or all 4 of the different virtualization environments at the same
time?

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: What is evdev and autoloading?

[Baptiste Daroussin]

On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote:
> > On 2/18/19 12:06 PM, Stefan Blachmann wrote:
> > > On 2/18/19, Vladimir Kondratyev  wrote:
> > >> On 2019-02-17 21:03, Steve Kargl wrote:
> > >>> Anyone have insight into what evdev is?
> > >> evdev.ko is a small in-kernel library that makes all your input events
> > >> like keyboard presses libinput-compatible.
> > > 
> > > And libinput was created by the Freedesktop Wayland team to create
> > > pressure on OS people to make their systems Wayland-compatible.
> > > 
> > >>> I do not need nor what these modules loaded.
> > >> I think removing "option EVDEV_SUPPORT" from your kernel config should
> > >> disable most of evdev.ko dependencies
> > > 
> > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well
> > > as libinput not be part of the standard packages?
> > > 
> > > The Freedesktop Wayland team consists of people with the Kay Sievers
> > > mentality, which made Linus Torvalds ban his contributions. They do
> > > not care about the bugs they introduce, forcing others to clean up the
> > > mess they create.
> > > 
> > > I'd be glad if FreeBSD would keep clean of following that Wayland fad...
> > 
> > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve 
> > input device handling in X and Wayland.  Not having it means that a lot 
> > of input devices stop working, or work much worse.
> > 
> > We in the FreeBSD Graphics Team are working very hard to improve the 
> > FreeBSD Desktop experience, since it is an avenue to recruit new users, 
> > and make current users use FreeBSD more.
> 
> Sadly your execution on that seems to be missing the mark,
> telling people they have to go get a port now to get drm working
> because it could not be maintained in base, and then telling them,
> oh, you need this new code in base so that it is so much easier
> to use graphical stuff this way.
> 
> These seem to be conflicting stories.
> 
You are missing the point, one does not evolve as fast as the other, meaning
one can be maintained within usual freebsd lifecycle, the other cannot or it
becomes very painful.

Bapt


signature.asc
Description: PGP signature

Re: What is evdev and autoloading?

[Rodney W. Grimes]

> On 2/18/19 12:06 PM, Stefan Blachmann wrote:
> > On 2/18/19, Vladimir Kondratyev  wrote:
> >> On 2019-02-17 21:03, Steve Kargl wrote:
> >>> Anyone have insight into what evdev is?
> >> evdev.ko is a small in-kernel library that makes all your input events
> >> like keyboard presses libinput-compatible.
> > 
> > And libinput was created by the Freedesktop Wayland team to create
> > pressure on OS people to make their systems Wayland-compatible.
> > 
> >>> I do not need nor what these modules loaded.
> >> I think removing "option EVDEV_SUPPORT" from your kernel config should
> >> disable most of evdev.ko dependencies
> > 
> > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well
> > as libinput not be part of the standard packages?
> > 
> > The Freedesktop Wayland team consists of people with the Kay Sievers
> > mentality, which made Linus Torvalds ban his contributions. They do
> > not care about the bugs they introduce, forcing others to clean up the
> > mess they create.
> > 
> > I'd be glad if FreeBSD would keep clean of following that Wayland fad...
> 
> EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve 
> input device handling in X and Wayland.  Not having it means that a lot 
> of input devices stop working, or work much worse.
> 
> We in the FreeBSD Graphics Team are working very hard to improve the 
> FreeBSD Desktop experience, since it is an avenue to recruit new users, 
> and make current users use FreeBSD more.

Sadly your execution on that seems to be missing the mark,
telling people they have to go get a port now to get drm working
because it could not be maintained in base, and then telling them,
oh, you need this new code in base so that it is so much easier
to use graphical stuff this way.

These seem to be conflicting stories.

> 
> Evdev and libinput is used by both Wayland and xorg.  You are free to 
> use either one.

And sadly now must take action when no action was required before
when using neither.

-- 
Rod Grimes rgri...@freebsd.org
___
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"

Fwd: What is evdev and autoloading?

[Johannes Lundberg]

Missed to include current@


 Forwarded Message 
Subject:Re: What is evdev and autoloading?
Date:   Mon, 18 Feb 2019 12:02:50 +
From:   Johannes Lundberg 
To: freebsd-hack...@freebsd.org




On 2/18/19 11:06 AM, Stefan Blachmann wrote:
> On 2/18/19, Vladimir Kondratyev  wrote:
>> On 2019-02-17 21:03, Steve Kargl wrote:
>>> Anyone have insight into what evdev is?
>> evdev.ko is a small in-kernel library that makes all your input events
>> like keyboard presses libinput-compatible.
> And libinput was created by the Freedesktop Wayland team to create
> pressure on OS people to make their systems Wayland-compatible.
>
>>> I do not need nor what these modules loaded.
>> I think removing "option EVDEV_SUPPORT" from your kernel config should
>> disable most of evdev.ko dependencies
> Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well
> as libinput not be part of the standard packages?

Evdev with libinput provide things like, multitouch gestures, horizontal
scrolling, touchpad support, etc, i.e. functionality that one might
expect from a laptop or desktop computer newer than 10 years,  also for X11.

Having it enabled by default doesn't force you to use it but it makes it
a whole lot easier for all of those who want to use it. Please try to
consider what is the best middle ground for ALL users. If you have a
special application for FreeBSD you're probably building your own kernel
anyway and it is easy to disable if needed. Most normal (and especially
new to FreeBSD) desktop/laptop users use stock kernel and would benefit
from having access to this functionality.

Cheers

> The Freedesktop Wayland team consists of people with the Kay Sievers
> mentality, which made Linus Torvalds ban his contributions. They do
> not care about the bugs they introduce, forcing others to clean up the
> mess they create.
>
> I'd be glad if FreeBSD would keep clean of following that Wayland fad...
> ___
> freebsd-hack...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

___
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: What is evdev and autoloading?

[Niclas Zeising]

On 2/18/19 12:06 PM, Stefan Blachmann wrote:

On 2/18/19, Vladimir Kondratyev  wrote:

On 2019-02-17 21:03, Steve Kargl wrote:

Anyone have insight into what evdev is?

evdev.ko is a small in-kernel library that makes all your input events
like keyboard presses libinput-compatible.


And libinput was created by the Freedesktop Wayland team to create
pressure on OS people to make their systems Wayland-compatible.


I do not need nor what these modules loaded.

I think removing "option EVDEV_SUPPORT" from your kernel config should
disable most of evdev.ko dependencies


Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well
as libinput not be part of the standard packages?

The Freedesktop Wayland team consists of people with the Kay Sievers
mentality, which made Linus Torvalds ban his contributions. They do
not care about the bugs they introduce, forcing others to clean up the
mess they create.

I'd be glad if FreeBSD would keep clean of following that Wayland fad...


EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve 
input device handling in X and Wayland.  Not having it means that a lot 
of input devices stop working, or work much worse.


We in the FreeBSD Graphics Team are working very hard to improve the 
FreeBSD Desktop experience, since it is an avenue to recruit new users, 
and make current users use FreeBSD more.


Evdev and libinput is used by both Wayland and xorg.  You are free to 
use either one.


Regards
--
Niclas Zeising
FreeBSD Graphics Team
___
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: What is evdev and autoloading?

[Stefan Blachmann]

On 2/18/19, Vladimir Kondratyev  wrote:
> On 2019-02-17 21:03, Steve Kargl wrote:
>> Anyone have insight into what evdev is?
> evdev.ko is a small in-kernel library that makes all your input events
> like keyboard presses libinput-compatible.

And libinput was created by the Freedesktop Wayland team to create
pressure on OS people to make their systems Wayland-compatible.

>> I do not need nor what these modules loaded.
> I think removing "option EVDEV_SUPPORT" from your kernel config should
> disable most of evdev.ko dependencies

Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well
as libinput not be part of the standard packages?

The Freedesktop Wayland team consists of people with the Kay Sievers
mentality, which made Linus Torvalds ban his contributions. They do
not care about the bugs they introduce, forcing others to clean up the
mess they create.

I'd be glad if FreeBSD would keep clean of following that Wayland fad...
___
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: What is evdev and autoloading?

[Mark Millard]

On 2019-Feb-17, at 18:35, Rodney W. Grimes  wrote:

>> On Sun, Feb 17, 2019 at 03:04:41PM -0800, Mark Millard wrote:
>>> 
>>> 
>>> On 2019-Feb-17, at 10:03, Steve Kargl  
>>> wrote:
>>> 
>>> Anyone have insight into what evdev is?  There appears to
>>> be no manual page.  When I reboot a system with custom
>>> kernel, the system is autoloading evdev.ko, uhid.ko, and
>>> wmt.ko.  I do not need nor what these modules loaded.
>>> How does one prevent this autoloading?
>>> 
>>> Looking via the web lead to:
> ^^^
> web lies

The URL I listed (below) is to www.freebsd.org/cgi/man.cgi?query. . .
and I looked at the page's content before sending the message. That
is how I got the text that I quoted. (It is from section 4 "special
files".)

The freeBSD manpage servers might provide more man pages than are
installed?

>>> 
>>> https://www.freebsd.org/cgi/man.cgi?query=evdev=0=4=FreeBSD+12.0-RELEASE=default=html
>>> So:
>>> 
>>> NAME
>>>   evdev - Generic Linux input driver
>>> 
>>> DESCRIPTION
>>> 
>>> evdev is an Xorg input driver for Linux's generic event devices. It
>>> therefore supports all input  devices  that  the kernel  knows about,
>>> including most mice, keyboards, tablets and touchscreens. evdev
>>> is the default driver on the major Linux distributions.
>>> . . .
>>> 
>>> 
>>> 
>>> but it seems to not have a 13-current entry. It does have
>>> a 12.0-RELEASE entry.
>>> 
>> 
>> Thanks.  Kinda odd that freebsd-current doesn't have a manual
>> page, but FreeBSD-12 does.
> 
> rgrimes@t400:~ % man evdev
> No manual entry for evdev
> rgrimes@t400:~ % man -k evdev
> apropos: nothing appropriate
> rgrimes@t400:~ % uname -a
> FreeBSD t400.dnsmgr.net 12.0-RELEASE FreeBSD 12.0-RELEASE GENERIC  amd64
> rgrimes@t400:~ % 
> There is no man page for evdev in 12.0-RELEASE
> 
>> 
>> I have a wireless logitech mouse.  It seems that the
>> wireless USB dongle is causing the load of the modules.
>> I still understand why as ums(4) does not should a 
>> dependency on uhid, wmt, or evdev.
> 



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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"