Re: Forcing a USB device to "ugen"

[Robert Swindells]

Jason Thorpe  wrote:
> I have a device based on the FTDI FT2232C:
>
> [ 3285.311079] uftdi1 at uhub1 port 2 configuration 1 interface 0
> [ 3285.311079] uftdi1: SecuringHardware.com (0x0403) Tigard V1.1 
> (0x6010), rev 2.00/7.00, addr 3
> [ 3285.311079] ucom1 at uftdi1 portno 1
> [ 3285.311079] uftdi2 at uhub1 port 2 configuration 1 interface 1
> [ 3285.311079] uftdi2: SecuringHardware.com (0x0403) Tigard V1.1 
> (0x6010), rev 2.00/7.00, addr 3
> [ 3285.311079] ucom2 at uftdi2 portno 2
>
> It's a combo device that, in addition to a standard TTL-level UART,
> has a bunch of break-out headers for doing things like SPI, SWD, and
> JTAG (in my case, I need to use JTAG for programming some Atmel
> CPLDs).  I should be able to do this with OpenOCD
> (pkgsrc/devel/openocd), but libfdti1 fails to find the device because
> libusb1 only deals in "ugen".

I thought that all FTDI devices provided JTAG etc. functionality, just
that the pins are not connected to anything in some devices.

What would be wrong with attaching an ugen to interface 1 instead of
an ucom in the ftdi driver itself?

Re: __futex(2): use outside Linux compat

[Robert Swindells]

tlaro...@kergis.com wrote:
> In Mesa code implementations for futex_wake() and futex_wait() are
> provided for Linux, Windows, FreeBSD and OpenBSD.
>
> There is a __futex(2) syscall in NetBSD, used only for now, if I'm not
> mistaken, to implement Linux compat.

The Linux emulation of futexes in NetBSD does not work correctly.

> Is it OK to use for NetBSD "native" code since it is not "advertised"
> by a man page?

No.

Re: ATI video card not recognized

[Robert Swindells]

Reinoud Zandijk  wrote:
>On Mon, Dec 04, 2023 at 04:15:39PM +0100, Reinoud Zandijk wrote:
>> On Tue, Jun 23, 2020 at 01:26:21PM +0200, Reinoud Zandijk wrote:
>> > my old videocard died and I replaced it with a slightly newer one but it 
>> > isn't
>> > recognized and nothing other than vga0 attaches. Its an Gigabyte Radeon 
>> > RX460
>> > with 2 GB ram.
>> > 
>> > 002:00:0: ATI Technologies Radeon RX460 (VGA display, revision 0xcf)
>> > 002:00:1: ATI Technologies Radeon RX 460/550/640SP, RX 560/560X HD Audio
>> > Controller (mixed mode multimedia)
>> > 
>> 
>> Back again :) I tried out the videocard again in 10.0 i(beta) and got a lot
>> further. However I still stumble on a panic when starting X :
>
> Another data point, Firefox with hardware acceleration is completely
> screwing up the display. GLXgears works fine though i still have some
> DRI access rights issues.

Have you checked whether this is using hardware acceleration in X11
itself?

What does 'glxinfo -B' print?

Re: [RFC] userconf(4) modification

[Robert Swindells]

tlaro...@kergis.com wrote:
> As stated in a message before, disabling, via userconf(4), all the
> drmkms drivers can not rely on a pattern matching since, for historical
> reasons (several versions of DRM), the namespace of the drivers is not
> "ruled".

I don't see the need for this, it would be unusual for more than one
drm driver to attach.

You can also build a custom kernel.

Re: drm.4 man page and import of X11 drm-kms.7 and al.

[Robert Swindells]

tlaro...@kergis.com wrote:
> So to clarify: I'm proposing to convert the rst doc pages to man
> pages (with for example the utility I cite), and to add the man pages,
> in man format, to the sources (in order for the sources to not depend
> on a supplementary external tool) and to install the man pages in 
> /usr/X11R7/man/.

I wouldn't bother installing man pages for this, someone working on the
kernel already has the source tree.

Maybe the drm.4 manpage could be extended to describe the current
status.

panic options

[Robert Swindells]

Is there any way to get panic(9) to behave differently in some places
than others?

There is a call to panic() if the kernel detects that there is no
console device found, I would like to make this call to it just reboot
without dropping into ddb.

The amdgpu driver fails to initialize about 9 times in 10 for me so
would like to reduce the amount of typing needed.

Re: Testing Emulation Syscalls

[Robert Swindells]

Theodore Preduta   wrote:
> This comes somewhat as a "part 2" to
> https://mail-index.netbsd.org/tech-kern/2023/06/21/msg028926.html
>
> Given the responses to that thread, I decided to add native stubs
> for epoll (the fact epoll is widespread alone justifies it, but it has
> already had some negative side effects, see:
> https://mail-index.netbsd.org/source-changes-d/2023/07/30/msg013999.html).

What is wrong with the suggestion in the thread on tech-userlevel@ to
just rename the header so that userland won't find it when configuring
packages?

Re: kcmp(2)

[Robert Swindells]

Jason Thorpe  wrote:
>> On Jul 18, 2023, at 2:57 PM, Mouse  wrote:
>> 
 What does Mesa use kcmp(2) for?
>>> Working out whether two device handles are to the same DRM device.
>> 
 Is there another way to accomplish what Mesa is trying to use it for?
>>> I don't know of one.
>> 
>> Is fstat() plus checking st_rdev (and possibly other fields)
>> insufficient?
>
> That *might* work in this particular case, but it would not work for
> e.g. a cloning device where you get additional descriptors via dup() or
> whatever.

Using fstat(2) does seem to work well enough for MesaLib, Xorg starts
up now for me.

Re: kcmp(2)

[Robert Swindells]

Taylor R Campbell  wrote:
> Date: Tue, 11 Jul 2023 22:00:25 +0100
> From: Robert Swindells 
> 
>> Linux has the kcmp(2) syscall, Mesa makes use of it.
>> 
>> Do we want a version of the syscall?
>
> Can you give any more details?
>
> What is kcmp(2) useful for?

It can compare two file descriptors to determine if they are for the
same or different files. There are online man pages for it.

The Linux implementation can compare handles to other kernel objects
as well but I don't think this functionality is needed right now.

Maybe it will be required for our Linux emulation at some point.

> Is kcmp(2) a good design for that goal?

It needs something like a syscall because the information on whether
the handles are to the same object is in the kernel.

> What does Mesa use kcmp(2) for?

Working out whether two device handles are to the same DRM device.

> Is there another way to accomplish what Mesa is trying to use it for?

I don't know of one.

> Is the functionality in Mesa optional or mandatory?

There is a wrapper function in Mesa that has one implementation for
Linux and one for everything else.

The non-Linux version just tests whether the fds are identical and
returns an error if not.

> If optional, what are the consequences of disabling it?

The xf86-video-amdgpu driver makes multiple attempts to startup the
GPU, the kernel DRM code doesn't seem to like this.

> What do operating systems other than Linux do?

They will print a warning:

   os_log_message("amdgpu: os_same_file_description couldn't "
  "determine if two DRM fds reference the same "
  "file description.\n"
  "If they do, bad things may happen!\n");

Re: DRM/KMS: vmwgfx driver is now available

[Robert Swindells]

PHO  wrote:
>On 7/16/23 01:24, Robert Swindells wrote:
>> 
>> PHO  wrote:
>>> I've been working on vmwgfx driver, a driver for VMware virtualized GPU.
>>> It was partly ported to NetBSD but wasn't buildable, and now it builds
>>> and actually works. (Thank you riastradh@, your prior work helped
>>> tremendously. I don't think I could do this without it.)
>> 
>> [snip]
>> 
>>> Note that you need to update your pkgsrc tree to try the driver, as I
>>> fixed a few things that needed fixing. Also the base X.org is not
>>> capable of making use of the driver because its Mesa is built without
>>> libxatracker. You need the modular one from pkgsrc.
>> 
>> Which bits of Mesa does it need apart from xa?
>
> Only this change:
> https://mail-index.netbsd.org/pkgsrc-changes/2023/07/14/msg278732.html

Which drivers or compiler backends does it use?

Re: DRM/KMS: vmwgfx driver is now available

[Robert Swindells]

PHO  wrote:
> I've been working on vmwgfx driver, a driver for VMware virtualized GPU. 
> It was partly ported to NetBSD but wasn't buildable, and now it builds 
> and actually works. (Thank you riastradh@, your prior work helped 
> tremendously. I don't think I could do this without it.)

[snip]

> Note that you need to update your pkgsrc tree to try the driver, as I 
> fixed a few things that needed fixing. Also the base X.org is not 
> capable of making use of the driver because its Mesa is built without 
> libxatracker. You need the modular one from pkgsrc.

Which bits of Mesa does it need apart from xa?

kcmp(2)

[Robert Swindells]

Linux has the kcmp(2) syscall, Mesa makes use of it.

Do we want a version of the syscall?

Re: Per-descriptor state

[Robert Swindells]

David Holland  wrote:
>On Sun, Apr 30, 2023 at 09:44:49AM -0400, Mouse wrote:
> > > Close-on-fork is apparently either coming or already here, not sure
> > > which, but it's also per-descriptor.
> > 
> > I should probably add that here, then, though use cases will likely be
> > rare.  I can think of only one program I wrote where it'd be useful; I
> > created a "close these fds post-fork" data structure internally.
>
>I can't think of any at all; to begin with it's limited to forks that
>don't exec, and unless just using it for convenience as you're
>probably suggesting, it only applies when also using threads, and if
>one's using threads why is one also using forks? So it seems like it's
>limited to badly designed libraries that want to fork behind the
>caller's back instead of setting up their forks at initialization
>time. Or something.

Or it is needed for a little used application called Firefox.

Re: debugging a kernel that doesn't start

[Robert Swindells]

>> The simplest way to debug something is using a serial port, do you have
>> access to the one on this machine?
>
>Yes, there is one. It seems to sort-of mirror the on-screen messages up to 
>the point the NetBSD boot runs. I tried
>   consdev com0,9600
>from the boot prompt but that hung the machine.

Why not try booting Linux on the thing to find out how the serial
port is configured.

Are you connecting another computer to the serial port on the back or
using the system management controller?

Re: debugging a kernel that doesn't start

[Robert Swindells]

Edgar Fuß  wrote:
> I'm trying to run NetBSD on a Dell PowerEdge R6515, and the kernel is being 
> loaded (PXE or USB) but then the machine hangs hard.

Have you tried booting a custom kernel with some drivers removed?

I tried PXE booting an i386 machine today using pxeboot_ia32.bin
from -current, worked fine. Just tried amd64 now as well, also
worked.

One thing I didn't try was to pxeboot a gzipped kernel, have you
tried an uncompressed one?

> What's the way to debug a kernel that hangs so early that you can't
> printf or drop into ddb? I guess that's a phenomenon quite common for
> a new port or changes to locore.s (or whatever that's called today),
> but it's completely new to me.

The simplest way to debug something is using a serial port, do you have
access to the one on this machine?

Extra DRM sources

[Robert Swindells]

I would like to import the source to some extra DRM drivers from Linux,
would do lima, panfrost and vc4.

The layout that I'm using in my own tree is to put the GPL ones in a
sys/external/gpl2/drm2 tree that mirrors the existing bsd/drm2 tree.

The lima sources apart from lima_regs.h are dual licenced so will put
them under bsd/drm2.

All files will be from the same v5.6-rc3 branch of Linux as the current
drm sources.

Do I need to do a vendor import of this or just add the files?

Robert Swindells

Re: [PATCH] ISO abd JIS for ADB (Was: two keys with same keycode on ADB)

[Robert Swindells]

Emmanuel Dreyfus  wrote:
>On Fri, May 13, 2022 at 01:44:31PM +0100, Robert Swindells wrote:
>> I have a UK keyboard, can try something with it.
>
>Just to make sure: my change is only for ADB keyboards.

Yes, you even put "ADB" in the thread title.

Re: [PATCH] ISO abd JIS for ADB (Was: two keys with same keycode on ADB)

[Robert Swindells]

Rhialto  wrote:
>On Thu 12 May 2022 at 22:54:44 -0400, Michael wrote:
>> Emmanuel Dreyfus  wrote:
>> 
>> > I am also a bit puzzled that in our historical code, ANSI ADB
>> > scancode 42, which is supposed to be backslash (the key is between
>> > backspace and return), is converted into USB scancode 50, which
>> > is non US hash. I did not change it, but here again, input from
>> > someone that has access to that keyboard would help.
>> 
>> It's there because hidkbdmap.c has
>> KC(50),  KS_backslash,   KS_bar,
>
>Could that have something to do with UK layout? The key near ENTER
>(but not as described between enter and backspace) is #/~.

I have a UK keyboard, can try something with it.

Re: Intel GPIO

[Robert Swindells]

Emmanuel Dreyfus  wrote:
>In order to get Goodix touchscreen working, I have been working on 
>Intel GPIO support, which I understand is required. Here is the 
>code so fat, inspired from Linux's drivers/pinctrl/intel:
>ftp://ftp.netbsd.org/pub/NetBSD/misc/manu/igpio20220125.patch
>
>I had very little success for now with the touchscreen, therefore I 
>am not even sure this code works. Is anyone in position to give it
>a try in another setup? Should I commit it as experimental?

Didn't someone post that the same touchscreen controller is used in
the Pinephone?

Could be a way to verify whether your GPIO code is working or not.

Re: Regulator

[Robert Swindells]

Taylor R Campbell  wrote:
> Date: Wed, 12 Jan 2022 15:42:17 +
>> From: Robert Swindells 
>> 
>> I'm guessing this is a platform that doesn't use FDT.
>> 
>> Maybe we need a more general API for regulators.
>
>What other instances would a more general API cover?  Is there some
>ACPI interface for regulators?

Don't know, somebody could look at what the Linux API covers.

Could also look at doing clocks, resets and interrupts.

>> The current situation causes a fair bit of "#ifdef FDT" in the drm
>> compat code.
>
>I count 1:
>
>Am I missing some?

sys/external/bsd/drm2/include/linux/clk.h

I didn't say they were all in the tree right now, I also have them in
interrupt.h and reset.h in my local working copy.

If you want this kind of thing done in a different way then say what it
should be.

>There's also one in linux/clk.h, for clocks, and two in nouveau_pci.c
>and radeon_pci.c, for kicking out the FBT framebuffer; these don't
>appear to be relevant to regulators.

Both lima and panfrost need to make calls to the regulator API, as well
as clock, reset and interrupt ones.

Re: Regulator

[Robert Swindells]

Jason Thorpe  wrote:
> On Jan 12, 2022, at 6:34 AM, Emmanuel Dreyfus  wrote:
>> 
>> Hello
>> 
>> I am still working on Goodix touchpanel as told in [1] and [2]. I
>> wrote a driver for the Intel GPIO chip that interfaces with Goodix
>> chipreset and interrupt pins. I have not committed yet, because it
>> remains untested.
>> 
>> There is another readblock. The Linux driver for Goodix touchpanel 
>> uses a beast called regulator, which seems to control the chip
>> power supply:
>>ts->avdd28 = devm_regulator_get(dev, "AVDD28");
>> (...)
>>ts->vddio = devm_regulator_get(dev, "VDDIO");
>> (...)
>>/* power up the controller */
>>error = regulator_enable(ts->avdd28);
>> (...)
>>error = regulator_enable(ts->vddio);
>> 
>> Is it another chip that neds another driver? Or a feature of the
>> Goodix chip?  What support do we have for thins kind of thing? 
>> grep -r regulator returns manu hits in src/sys/dev/i2c and
>> src/sys/dev/fdt but we do not have any generic API for that, right?

>We support regulators using FDT.

I'm guessing this is a platform that doesn't use FDT.

Maybe we need a more general API for regulators.

The current situation causes a fair bit of "#ifdef FDT" in the drm
compat code.

Re: kaveri_mec2.bin file missing

[Robert Swindells]

Riza Dindir  wrote:
>I have put the two files listed above (by RVP) to the
>"src/sys/dev/microcode/radeon/" directory. I also changed the
>configuration to only include the radeon device that is the
>0x1002/0x1309 Kaveri device. Did add the KAVERI_mec2.bin to the
>MODULE_FIRMWARE definitions in the radeon_cik.c file (since this was
>missing). But this failed to load the microcode. It does fail in the
>function "cik_init_microcode".
>
>I have put these bin files into "src/sys/dev/microcode/radeon/". Isn't
>this the correct path to put these bin files in?

It is the correct source directory for Radeon microcode files, unless
you have added something to the Makefile they won't get copied to
the destination directory which is /libdata/firmware/radeon.

You could just copy files from the linux-firmware tree to
/libdata/firmware/radeon to test things.

>Are the file names in this directory case-sensitive? Although in the
>"src/sys/dev/microcode/radeon/" directory all the bin files begin with
>capital letters (KAVERI_mec.bin for instance).

The filenames are case sensitive, you can see that the files are not the
same.

% diff -b KAVERI_me.bin kaveri_me.bin
Binary files KAVERI_me.bin and kaveri_me.bin differ

I would expect to use either the KAVERI* or the kaveri* files as a set.

Re: [PATCH] Move DRM-driver firmware from base to its own set, gpufw

[Robert Swindells]

David Brownlee  wrote:
>
>If gpu firmware is somewhat special, is there any sense in moving it
>to /usr/libdata/firmware/gpu/... ?

No.

It needs to be in /libdata so that it is guaranteed to be on the boot
filesystem.

Re: timeouts connecting to pgsql database

[Robert Swindells]

Derrick Lobo  wrote:
>Robert Swindells  wrote
>>Derrick Lobo  wrote:
>>>Not sure if anyone else has experienced the below, postgres configs can be
>>>shared if needed, we have a few database servers running on 7.12 and 9
>>>
>>>We recently noticed some problems with timeouts on some postgres database
>>>servers. The machines don't appear to be heavily loaded, although they are
>>>being used steadily. What we're seeing is that the machine is working fine.
>>>No swapping, load average is below 1, and then it doesn't accept database
>>>connections for about 10-20 seconds, and any queries on active connections
>>>fail to return for that same time period. I tried running these commands in a
>>>screen to get a better sense of the system state when the problem occurs: 
>>
>>What filesystem options are you using for wherever the database files
>>are located ? Are you using wapbl(4) ?
>
>Rw,log,noatime are the options used

Thought it might be.

I would not run a database on a filesystem with 'log' enabled, I think
you will find that the delay is when it is flushing the log to disk.

Re: timeouts connecting to pgsql database

[Robert Swindells]

Derrick Lobo  wrote:
>Not sure if anyone else has experienced the below, postgres configs can be
>shared if needed, we have a few database servers running on 7.12 and 9
>
>We recently noticed some problems with timeouts on some postgres database
>servers. The machines don't appear to be heavily loaded, although they are
>being used steadily. What we're seeing is that the machine is working fine. No
>swapping, load average is below 1, and then it doesn't accept database
>connections for about 10-20 seconds, and any queries on active connections
>fail to return for that same time period. I tried running these commands in a
>screen to get a better sense of the system state when the problem occurs: 

What filesystem options are you using for wherever the database files
are located ? Are you using wapbl(4) ?

Re: Issues with older wd* / IDE on various platforms

[Robert Swindells]

John Klos  wrote:
>I've noticed problems in three places and only recently did it occur to me 
>that they may all be related.

[snip]

>All three of these machines have much older IDE, so I'm wondering what in 
>NetBSD changed that may've have caused this.

I would guess that one thing all have in common is lack of DMA.

I have been using a local patch for an ofppc machine that can only do
PIO with the IDE controller, can try latest -current on it over the
weekend.

Index: atapi_wdc.c
===
RCS file: /cvsroot/src/sys/dev/scsipi/atapi_wdc.c,v
retrieving revision 1.138
diff -u -r1.138 atapi_wdc.c
--- atapi_wdc.c	13 Apr 2020 10:49:34 -	1.138
+++ atapi_wdc.c	13 Nov 2020 21:28:04 -
@@ -739,7 +739,7 @@
 #if NATA_DMA
 	int error;
 #endif
-#if NATA_DMA || NATA_PIOBM
+#if NATA_DMA
 	int dma_flags = 0;
 #endif
 	void *cmd;
@@ -831,7 +831,7 @@
 	 * previously recorded, else continue normal processing
 	 */
 
-#if NATA_DMA || NATA_PIOBM
+#if NATA_DMA
 	if (xfer->c_flags & (C_DMA | C_PIOBM))
 		dma_flags = (sc_xfer->xs_control & XS_CTL_DATA_IN)
 		?  WDC_DMA_READ : 0;

Re: boot -d

[Robert Swindells]

 wrote:
>> I‘ve backported the fixes, will post them later.
>
>Here they are (for netbsd-8). I can boot -d with them, but because of
>the spdmem panics, I can't tell whether the machine would run with them.

Why not take spdmem out of your kernel config for now and test the
pmap patches ?

Re: Funded project(s) to improve Linux emulation

[Robert Swindells]

Martin Husemann  wrote:
>The NetBSD core team is looking at finding volunteers or funded workers
>willing to help improve our linux emulation. We have an offer from
>Precedence Technologies to co-fund some of this developement, especially
>the Citrix sub-projects.
>
>The tasks we are looking for takers are:
>
> - Improve compat linux on arm

Does it work at all ?

Linux on arm makes use of a page mapped at the top of the 32-bit address
space containing some "helper" functions to do things like get thread
local storage.

I had a go at adding a pmap_helper() for Linux processes but didn't get
it to work.

> - Extend support for the Citrix Workspace App to some arm platform(s).

Is this still arm or is there a requirement to be able to run an aarch64
application ?

> - Add support for linux drm (DRI kernel support) for the version of DRI
>   we support natively by the time this project runs.

Think we would want newer DRI kernel code to be able to use the Linux
drivers for ARM GPUs, the Mali code makes use of the dri scheduler which
isn't in our tree.

Re: futexes

[Robert Swindells]

Is there any way we can make progress with getting futexes to work
properly ?

At least post the latest non-working source somewhere so that people can
try debugging it.

Robert Swindells

Re: futexes

[Robert Swindells]

Jason Thorpe  wrote:
> On Aug 16, 2020, at 5:58 AM, Robert Swindells  wrote:
> 
> 
> Taylor R Campbell  wrote:
>>> Date: Sat, 15 Aug 2020 19:59:24 +0100
>>> From: Robert Swindells 
>>> 
>>> Is anyone working on the proposed solution to kern/55230 ?
>> 
>> thorpej was working on it and has a patch -- I thought it got
>> committed, but I guess not?  There might have been some hard-to-fix
>> bug remainining in it but I forget the details.
> 
> Would it help to have more people testing and/or looking at it ?

>The fix is non-trivial, and requires a fundamental change to how futexes
>work.

That seemed clear in the bug, I guessed it would mean switching to using
a futex_syncobj (or similar).

>That said, I've made the change, and it fixes the unit test, and to
>exercise it more thoroughly, I also started converting several pthread
>locking interfaces to use futex beneath, while also enhancing the test
>cases for those pthread interfaces to verify proper priority ordering.
>However, the changes started to grow without bound and then I ran into a
>time crunch.
>
>What I should do is wind my code back to the basic "just fix the futex
>internals" change, and publish there so that others can work on it.  The
>main sticking point is that Linux Java was getting stuck ... all of my
>unit tests were passing, however.  This is why I started working on
>native users -- to provide more coverage and possibly make it easier to
>debug that problem.

I'm mainly interested in Linux Java, it seemed fairly easy to find
test cases that got stuck.

Happy to do some work on simplifying the patch, or just identifying
good test cases, if it will help.

Re: futexes

[Robert Swindells]

Taylor R Campbell  wrote:
>> Date: Sat, 15 Aug 2020 19:59:24 +0100
>> From: Robert Swindells 
>> 
>> Is anyone working on the proposed solution to kern/55230 ?
>
>thorpej was working on it and has a patch -- I thought it got
>committed, but I guess not?  There might have been some hard-to-fix
>bug remainining in it but I forget the details.

Would it help to have more people testing and/or looking at it ?

futexes

[Robert Swindells]

Is anyone working on the proposed solution to kern/55230 ?

Re: Straw proposal: MI kthread vector/fp unit API

[Robert Swindells]

Jason Thorpe  wrote:
>> On Jun 20, 2020, at 6:52 PM, Erik Fair  wrote:
>> 
>> Has anyone using NetBSD played with FPGAs embedded with a processor? I
>> know that Intel was talking about adding some to its processors after
>> they bought Altera in 2015. There is explicit provision for FPGAs in
>> OpenCL, alongside GPUs:
>
>NetBSD runs on the Xilinx Zynq.

And on the Altera/Intel Cyclone.

stat(2) performance

[Robert Swindells]

Doing a 'cvs update' feels really slow

Running it under ktrace(1) shows it doing a stat(2) for every metadata
file in the tree. The machine sounds like it is hitting the disk for
every one. Is there any kind of cache for the attribute information
that stat needs ?

This is on a ffs filesystem mounted log,noatime.

Re: makesyscalls (moving forward)

[Robert Swindells]

Johnny Billquist  wrote:
>On 2020-06-14 23:21, Paul Goyette wrote:
>> On Sun, 14 Jun 2020, David Holland wrote:
>> 
>> 
>> 
>>> This raises two points that need to be bikeshedded:
>>>
>>> (1) What's the new tool called, and where does it live in the tree?
>>> "usr.bin/makesyscalls" is fine with me but ymmv.
>> 
>> "usr.bin/makesyscalls" sounds good to me.
>
>Uh? usr.bin is where stuff for /usr/bin is located, right? Anything 
>there should be pretty normal tools that any user might be interested 
>in. Don't seem to me as makesyscalls would be a tool like that?

As config(1) is in /usr/bin that seems the best place for makesyscalls
too.

I would expect that the generated files would have the developer uid and
gid, I wouldn't want them owned by root.

Re: NULL pointer arithmetic issues

[Robert Swindells]

Kamil Rytarowski  wrote:
>We still maintain compatibility with this behavior (originated as a hack
>in PDP11) in older NetBSD releases (NetBSD-0.9 Franz Lisp binaries
>depend on this).

I presume this was built for NetBSD/vax.

A 68k build of Franz Lisp wouldn't try to dereference a NULL pointer.

Re: non-module build fail

[Robert Swindells]

Manuel Bouyer  wrote:
>On Tue, Sep 10, 2019 at 04:38:46PM +0100, Robert Swindells wrote:
>> 
>> Manuel Bouyer  wrote:
>> >I'm trying to build a evbarm kernel with 
>> >options SLJIT
>> >options BPFJIT
>> 
>> Are you building a 32 or 64-bit kernel ?
>
>32-bits.

Try this:

Index: files.generic
===
RCS file: /cvsroot/src/sys/arch/evbarm/conf/files.generic,v
retrieving revision 1.7
diff -u -r1.7 files.generic
--- files.generic   11 Jun 2019 13:01:48 -  1.7
+++ files.generic   10 Sep 2019 15:53:24 -
@@ -26,3 +26,9 @@
 include "arch/arm/vexpress/files.vexpress"
 include "arch/arm/virt/files.virt"
 include "arch/arm/xilinx/files.zynq"
+
+#
+# Stack-less Just-In-Time compiler
+#
+
+include"external/bsd/sljit/conf/files.sljit"

Re: non-module build fail

[Robert Swindells]

Manuel Bouyer  wrote:
>I'm trying to build a evbarm kernel with 
>options SLJIT
>options BPFJIT

Are you building a 32 or 64-bit kernel ?

Re: Linux futexes

[Robert Swindells]

Jason Thorpe  wrote:
>> On Jul 27, 2019, at 5:05 AM, Robert Swindells  wrote:
>> 
>> I don't think the Linux futex emulation code is correct/good enough.
>
>I have be on/off working on an updated futex implementation written by
>Taylor, with the intent of making it a native call (in order to improve
>or own semaphore and mutex implementations).  You are correct in that
>the current implementation is lacking.
>
>I will try to focus on finishing up the new implementation soon.  But
>even the stuff written by Taylor is a little lacking compared to what
>modern Linux uses futexes for, so some additional work is going to be
>required.

Linux OpenJDK isn't using any extra futex features, it isn't using a
bitmask to selectively wake up threads for example, it just seems to
get into a loop of waking threads up then all of them going back to
sleep.

Robert Swindells

Linux futexes

[Robert Swindells]

I don't think the Linux futex emulation code is correct/good enough.

Trying to use Linux OpenJDK 11 to compile itself it stops making
any progress fairly quickly with all threads blocked waiting on
a futex.

Also seen with the installer for the latest Xilinx Vivado FPGA tools,
the UI stops responding to mouse clicks after one action has been
selected.

Robert Swindells

uuidgen(2)

[Robert Swindells]

The man page for the uuidgen(2) system call states that generated UUIDs
conform to the DCE version 1 variant which is based on the time they
were created.

The kernel actually generates version 4 UUIDs which are generated
randomly.

Found by wiz@ because the python test suite fails if you build python37
to use our uuid functions in libc instead of linking against the
devel/libuuid package. The test that fails is just a check of the UUID
version number.

Re: Bumping default data size limit on amd64?

[Robert Swindells]

Colin Percival  wrote:
>On 2017-02-03 06:52, Thomas Klausner wrote:
>> When testing security/scrypt, the self tests fail with the default
>> ulimits because one of the test needs 256MB. (After raising the data
>> size ulimit, the test succeeds.)
>> 
>> Colin Percival suggests that we change the port's defaults here.
>> 
>> DFLDSIZ in arch/amd64/include/vmparam.h was last bumped back in 2004.
>> 
>> He suspects that this would have been increased a long time ago if it
>> weren't for the fact that malloc allocates pages via mmap.
>> 
>> Anyway, opinions?
>
>Digging through my archives, I just found this email from two years ago.
>It looks like nobody had any opinions at the time -- maybe we can take a
>lack of objections as agreement and increase this value now?

There would probably have been more pressure to increase the default
data size in NetBSD if we checked whether the total amount of mmaped
memory was less than the limit rather than just checking each chunk.

Re: sys/malloc.h

[Robert Swindells]

co...@sdf.org wrote:
>I'm working on an import of a giant pile of code, and ran into the
>following build error:
>
>drm_gem.c:987:23: error: macro "free" requires 2 arguments, but only 1 given
>   obj->funcs->free(obj);
>   ^
>
>This was confusing for a bit, but apparently is due to sys/malloc.h:
>
>#definefree(addr, type)kern_free(addr)
>
>This feels like a recipe for subtle bugs.
>What's our plan for this code?

I thought that we were supposed to eventually replace usage of
malloc/free/realloc in kernel code with the kern_*() equivalents.

What breaks if the three macros are commented out ?

Re: Removing PF

[Robert Swindells]

On 2019-04-01 22:30, Johnny Billquist wrote:

On 2019-04-01 15:16, Emmanuel Dreyfus wrote:

On Sat, 30 Mar 2019, Maxime Villard wrote:
2) If the effort had been on one firewall instead of three, the one 
chosen

would be more functional.


Well, I cannot tell for PF, but IPF is functionnal, I use it a lot and 
I

am not alone It may have bugs, but if you really have to remove it,
please make sure there is an easy migration path.


Yeah. I happen to use ipf as well.

Anecdotal it would appear that npf might be the least tested or used 
option...


I'm using npf, it works fine for what I need.

The NetBSD project machines are using npf too, so it does get some real 
world

testing.

Re: USB error checking

[Robert Swindells]

mlel...@serpens.de (Michael van Elst) wrote:
>r...@fdy2.co.uk (Robert Swindells) writes:
>
>>I have now got it to drop into DDB and found that it is triggering an
>>assertion in sys/arch/arm/arm32/bus_dma.c:_bus_dmamap_sync().
>
>>KASSERTMSG(len > 0 && offset + len <= map->dm_mapsize,
>>"len %lu offset %lu mapsize %lu",
>>len, offset, map->dm_mapsize);
>
>Or just correct this assertion, len == 0 isn't invalid.

The same assertion is in other architectures as well, not just ARM.

USB error checking

[Robert Swindells]

I posted a few weeks ago that I could reboot my Pinebook by doing:

% cat /dev/video0 > foo.jpg

I have now got it to drop into DDB and found that it is triggering an
assertion in sys/arch/arm/arm32/bus_dma.c:_bus_dmamap_sync().

KASSERTMSG(len > 0 && offset + len <= map->dm_mapsize,
"len %lu offset %lu mapsize %lu",
len, offset, map->dm_mapsize);

with len = 0.

I'm guessing that the video camera is returning bad USB packets.

Could we put some more checking into the USB stack to ignore zero length
frames and not try to do cache synchronization operations for them ?

The traceback is:

_bus_dmamap_sync()
usb_transfer_complete()
ehci_softintr()
usb_soft_intr()
softint_dispatch()
cpu_switchto_softint()

Don't have a core dump as the ARM images only have a small swap
partition.

Robert Swindells

Re: svr4, again

[Robert Swindells]

Kamil Rytarowski  wrote:
>On 20.12.2018 17:58, Jason Thorpe wrote:
>> 
>> 
>>> On Dec 20, 2018, at 8:52 AM, Terry Moore  wrote:
>>>
>>> Kamil Rytarowski wrote:
> While I agree that it’s not exactly difficult to maintain the a.out exec 
> package, I do wonder if there is anyone out there actually running 
> ancient a.out binaries.
>

 NetBSD 0.9 i386 a.out yes.
>>>
>>> Here, too.
>> 
>> Well, then you have my sympathies, my admiration, and my curiosity all at 
>> the same time!
>> 
>> No, seriously, what ancient binaries are you running?  (Ok, I admit, it's 
>> pretty cool that it still works after all this time...)
>> 
>> -- thorpej
>> 
>
>https://github.com/krytarowski/franz-lisp-netbsd-0.9-i386

Maybe worth pointing out that to use that package you would also need
an a.out gcc toolchain.

The Lisp compiler generates C that you then compile and link into the
running Lisp executable.

Re: pci_intr_alloc() vs pci_intr_establish() - retry type?

[Robert Swindells]

Jared McNeill  wrote:
>On Wed, 28 Nov 2018, Jaromír Doleček wrote:
>
>> pci_intr_alloc() checks what the device claims to support down the
>> call stack, reading the PCI config space. I assume there some
>> negotiation between the PCI bus and the device. I hope device can't
>> claim to support e.g. MSI-X if the bus doesn't.
>
>Device claiming to support MSI-X is fine. The bus should only set 
>PCI_FLAGS_MSIX_OKAY in its pcibus_attach_args pba_flags in the case that 
>MSI-X is supported, and then the MD code will filter it out:

I traced through what one of my non-MSI machines does at boot.

The wm(4) driver asks for MSI-X interrupts, the MD PCI code gives it an
INTx interrupt, the driver sets things up correctly to use the returned
interrupt, it doesn't loop in the driver retrying the pci_intr_alloc().

Re: pci_intr_alloc() vs pci_intr_establish() - retry type?

[Robert Swindells]

Jaromir Dolecek  wrote:
>I see several drivers (e.g. xhci(4), ahcisata(4), bge(4), nvme(4))
>retry the pci_intr_alloc()+pci_intr_establish() with 'lower' types
>when pci_intr_establish() fails.
>
>Is this a real case, can it actualy happen that pci_intr_alloc()
>returns the interrupt handlers, but pci_intr_establish() would fail
>for it?
>
>If it's not a real case, it would be nice to remove all that boilerplate code.

I have several amd64 systems that don't do MSI/MSIX.

It looks to me that drivers try MSI and/or MSIX first based on the
device type not on whether the host controller can handle it.

I can add some debug to see what is going on.

Robert Swindells

Re: Things not referenced in kernel configs, but mentioned in files.*

[Robert Swindells]

co...@sdf.org wrote:
>This is an automatically generated list with some hand touchups, feel
>free to do whatever with it. I only generated the output.

Maybe we could put your list somewhere under src/doc, src/doc/ORPHANS ?

Then delete lines as we add them to one or other of the ALL configs.

Re: NetBSD-8 kernel too big?

[Robert Swindells]

Paul Goyette  wrote:
>I've been running a load-everything-as-modules-when-needed system for
>years.  :)  My 8.99.22 kernel weighs in at under 12MB:
>
>-rwxr-xr-x  1 root  wheel  12102488 Jul 26 14:00 /netbsd

I don't even build modules, this is the kernel on my main machine:

-rwxr-xr-x  1 root  wheel  11732560 Aug 27 12:56 /netbsd

Re: ddb input via IPMI virtual console

[Robert Swindells]

Edgar Fuß 
>> Can I have ddb input multiplexed from both PS/2 and USB?
>To elaborate: I have

[snip]

>and during normal operation, the virtual console does work as expected.
>It's only when the machine panics that I can see on the virtual console what 
>I would see on the VGA monitor, I just can't enter ddb commands.

For a USB keyboard to work with DDB you would need to have a working USB
stack. If the kernel has paniced then this won't be true.

Re: sysutils/grub2: multiboot is still working?

[Robert Swindells]

Frédéric Fauberteau  wrote:
>Le 2018-08-01 19:02, Robert Swindells a écrit :
>> Frédéric Fauberteau  wrote:
>>> grub-mkconfig generates (in a submenu) lines for both boot methods:
>>> - knetbsd
>>> - multiboot
>>> but when I select the multiboot choice, I get the following errors:
>>> --- grub error ---
>>> error: no multiboot header found.
>>> error: kernel must be loaded first.
>>> 
>>> Press key to continue... (approximate translation since messages are
>>> i18ned)
>>> --- /grub error ---
>>> 
>>> The line from grub.cfg is:
>>> multiboot /netbsd /netbsd root=dk3  -z
>>> but
>>> multiboot /netbsd
>>> does not work either
>>> 
>>> I plan to investigate, but if multiboot is broken, the reason becomes
>>> obvious...
>> 
>> Have you got MULTIBOOT defined in your kernel config ?
>
>$ uname -v
>NetBSD 8.0 (HYDRALISK) #1: Tue Jul 31 18:43:06 CEST 2018  
>root@hydralisk:/usr/obj/sys/arch/amd64/compile/HYDRALISK
>$ grep MULTIBOOT /usr/src/sys/arch/amd64/conf/HYDRALISK
>options MULTIBOOT

I think that only NetBSD/i386 is able to load using multiboot, not
NetBSD/amd64.

A test of the grub2 package might be to build sysutils/xenkernel48
for amd64 and try to boot that.

Re: sysutils/grub2: multiboot is still working?

[Robert Swindells]

Frédéric Fauberteau  wrote:
>grub-mkconfig generates (in a submenu) lines for both boot methods:
>- knetbsd
>- multiboot
>but when I select the multiboot choice, I get the following errors:
>--- grub error ---
>error: no multiboot header found.
>error: kernel must be loaded first.
>
>Press key to continue... (approximate translation since messages are 
>i18ned)
>--- /grub error ---
>
>The line from grub.cfg is:
> multiboot /netbsd /netbsd root=dk3  -z
>but
> multiboot /netbsd
>does not work either
>
>I plan to investigate, but if multiboot is broken, the reason becomes 
>obvious...

Have you got MULTIBOOT defined in your kernel config ?

Is there a reason why you don't want to use the NetBSD bootloader ?

Re: ioctl(2) numbers

[Robert Swindells]

Robert Elz  wrote:
>Date:Wed, 01 Aug 2018 10:56:28 +0100
>From:    Robert Swindells 
>Message-ID:  
>
>  | Does it matter if ioctl(2) numbers overlap so long as they are in
>  | different groups ?
>
>To expand on thorpej's answer ... an "ioctl nulmber" is a 32 bit
>constant which we typically build from a character (8 bits) an
>integer (8 bits) and an argument size (13 bits), with 3 more bits
>of no-copy, copy-in, copy-out.
>
>If the 32 bit result is different from all others, all is fine. 

I understand how ioctl works.

I asked because it looked as if there was a convention within that file
that numbers be unique, even if they were in different groups.

Robert Swindells

Re: New getsockopt2() syscall

[Robert Swindells]

chris...@zoulas.com (Christos Zoulas) wrote:
>On Jun 24, 11:18pm, r...@fdy2.co.uk (Robert Swindells) wrote:
>-- Subject: Re: New getsockopt2() syscall
>
>How about merging them thusly?
>
>christos
>
>Index: uipc_syscalls.c
>===
>RCS file: /cvsroot/src/sys/kern/uipc_syscalls.c,v
>retrieving revision 1.194
>diff -u -p -u -r1.194 uipc_syscalls.c
>--- uipc_syscalls.c4 May 2018 08:47:55 -   1.194
>+++ uipc_syscalls.c24 Jun 2018 23:28:14 -
>@@ -1192,18 +1192,10 @@ sys_setsockopt(struct lwp *l, const stru
>   return error;
> }

[snip]
 
>+int
>+sys_getsockopt2(struct lwp *l, const struct sys_getsockopt2_args *uap,
>+register_t *retval)
>+{
>+  /* {
>+  syscallarg(int) s;
>+  syscallarg(int) level;
>+  syscallarg(int) name;
>+  syscallarg(void *)  val;
>+  syscallarg(unsigned int *)  avalsize;
>+  } */
>+  return getsockopt(l, uap, retval, true);
>+}
>+
> #ifdef PIPE_SOCKETPAIR
> 
> int

I needed to cast the syscall args to get it to build but other than that
it does work.

+int
+sys_getsockopt2(struct lwp *l, const struct sys_getsockopt2_args *uap,
+register_t *retval)
+{
+   /* {
+   syscallarg(int) s;
+   syscallarg(int) level;
+   syscallarg(int) name;
+   syscallarg(void *)  val;
+   syscallarg(unsigned int *)  avalsize;
+   } */
+   return getsockopt(l, (const struct sys_getsockopt_args *) uap, retval, 
true);
+}
+

Re: New getsockopt2() syscall

[Robert Swindells]

chris...@zoulas.com (Christos Zoulas) wrote:
>On Jun 24,  7:47pm, r...@fdy2.co.uk (Robert Swindells) wrote:
>-- Subject: Re: New getsockopt2() syscall
>
>| What about the syscall implementation itself ?
>
>Where is the code for that?

Here:

<http://mail-index.netbsd.org/tech-kern/2018/03/06/msg023161.html>

With the only change that I'm now using number 193 for it.

Re: New getsockopt2() syscall

[Robert Swindells]

chris...@astron.com (Christos Zoulas) wrote:
>In article ,
>Robert Swindells   wrote:
>>
>>chris...@zoulas.com (Christos Zoulas) wrote:
>>>On Jun 9,  2:20pm, r...@fdy2.co.uk (Robert Swindells) wrote:
>>>-- Subject: Re: New getsockopt2() syscall
>>>
>>>| What is the best way to provide it for review, diffs or the complete
>>>| page ?
>>>
>>>Either way. I think that the complete man page is not too long (I
>>>just looked).
>>
>>This is my first go at it as diffs, the complete page is 14k.
>
>LGTM.

What about the syscall implementation itself ?

Re: New getsockopt2() syscall

[Robert Swindells]

Martin Husemann  wrote:
>On Sat, Jun 09, 2018 at 10:22:06AM +0200, Kamil Rytarowski wrote:
>> Can we reuse unused old syscall numbers?
>
>Reuse in general not (that would break any possible compat for that).
>But there are some unused numbers like 193 and 267-269.

I have switched to using 193.

Re: New getsockopt2() syscall

[Robert Swindells]

chris...@zoulas.com (Christos Zoulas) wrote:
>On Jun 9,  2:20pm, r...@fdy2.co.uk (Robert Swindells) wrote:
>-- Subject: Re: New getsockopt2() syscall
>
>| What is the best way to provide it for review, diffs or the complete
>| page ?
>
>Either way. I think that the complete man page is not too long (I just looked).

This is my first go at it as diffs, the complete page is 14k.

Index: getsockopt.2
===
RCS file: /cvsroot/src/lib/libc/sys/getsockopt.2,v
retrieving revision 1.35
diff -u -r1.35 getsockopt.2
--- getsockopt.225 Jan 2012 00:28:35 -  1.35
+++ getsockopt.216 Jun 2018 21:00:31 -
@@ -34,7 +34,8 @@
 .Os
 .Sh NAME
 .Nm getsockopt ,
-.Nm setsockopt
+.Nm setsockopt ,
+.Nm getsockopt2
 .Nd get and set options on sockets
 .Sh LIBRARY
 .Lb libc
@@ -44,10 +45,13 @@
 .Fn getsockopt "int s" "int level" "int optname" "void * restrict optval" 
"socklen_t * restrict optlen"
 .Ft int
 .Fn setsockopt "int s" "int level" "int optname" "const void *optval" 
"socklen_t optlen"
+.Ft int
+.Fn getsockopt2 "int s" "int level" "int optname" "void * restrict optval" 
"socklen_t * restrict optlen"
 .Sh DESCRIPTION
-.Fn getsockopt
-and
+.Fn getsockopt ,
 .Fn setsockopt
+and
+.Fn getsockopt2
 manipulate the
 .Em options
 associated with a socket.
@@ -82,10 +86,18 @@
 .Fn setsockopt .
 For
 .Fn getsockopt
+and
+.Fn getsockopt2
 they identify a buffer in which the value for the
 requested option(s) are to be returned.
 For
-.Fn getsockopt ,
+.Fn getsockopt2
+they are also used to provide an extra argument to select which
+value to return.
+For
+.Fn getsockopt
+and
+.Fn getsockopt2 ,
 .Fa optlen
 is a value-result parameter, initially containing the
 size of the buffer pointed to by
@@ -148,6 +160,8 @@
 The following options are recognized at the socket level.
 Except as noted, each may be examined with
 .Fn getsockopt
+or
+.Fn getsockopt2
 and set with
 .Fn setsockopt .
 .Bl -column SO_ACCEPTFILTER data -offset indent
@@ -379,7 +393,9 @@
 and
 .Dv SO_ERROR
 are options used only with
-.Fn getsockopt .
+.Fn getsockopt
+or
+.Fn getsockopt2 .
 .Dv SO_TYPE
 returns the type of the socket, such as
 .Dv SOCK_STREAM ;
@@ -444,5 +460,10 @@
 .Fn getsockopt
 system call appeared in
 .Bx 4.2 .
+.Pp
+The
+.Fn getsockopt2
+system call appeared in
+.Nx 9.0 .
 .Sh BUGS
 Several of the socket options should be handled at lower levels of the system.

Re: New getsockopt2() syscall

[Robert Swindells]

Kamil Rytarowski  wrote:
>On 08.06.2018 23:18, Robert Swindells wrote:
>> 
>> Are there any objections to the code for a getsockopt2() syscall
>> in:
>> 
>> <http://mail-index.netbsd.org/tech-kern/2018/03/06/msg023161.html>
>> 
>
>Can we reuse unused old syscall numbers?

Why ? We are not going to run out of them any time soon.

An "invalid syscall" error seems much easier to diagnose if an old
binary tries to call something that has been removed than getting
an argument error.

Re: New getsockopt2() syscall

[Robert Swindells]

chris...@astron.com (Christos Zoulas) wrote:
>In article ,
>Robert Swindells   wrote:
>>
>>Are there any objections to the code for a getsockopt2() syscall
>>in:
>>
>><http://mail-index.netbsd.org/tech-kern/2018/03/06/msg023161.html>
>
>Let's write the man page to see if it makes sense :-)

What is the best way to provide it for review, diffs or the complete
page ?

New getsockopt2() syscall

[Robert Swindells]

Are there any objections to the code for a getsockopt2() syscall
in:

Re: getsockopt(2)

[Robert Swindells]

chris...@astron.com (Christos Zoulas) wrote:
>In article <x7d135tur5@ren.fdy2.co.uk>,
>Robert Swindells  <r...@fdy2.co.uk> wrote:
>>
>>What is wrong with your idea of updatesockopt(2) ? Or maybe call it
>>getsockopt2() and only use it for the "get with extra argument" case.
>
>I guess getsockopt2/updatesockopt is not that bad after all. Perhaps
>we should go with that?

This is working for me:

Index: uipc_syscalls.c
===
RCS file: /cvsroot/src/sys/kern/uipc_syscalls.c,v
retrieving revision 1.191
diff -u -r1.191 uipc_syscalls.c
--- uipc_syscalls.c 12 Feb 2018 16:01:35 -  1.191
+++ uipc_syscalls.c 6 Mar 2018 00:47:02 -
@@ -1266,6 +1266,68 @@
return error;
 }
 
+int
+sys_getsockopt2(struct lwp *l, const struct sys_getsockopt2_args *uap,
+register_t *retval)
+{
+   /* {
+   syscallarg(int) s;
+   syscallarg(int) level;
+   syscallarg(int) name;
+   syscallarg(void *)  val;
+   syscallarg(unsigned int *)  avalsize;
+   } */
+   struct sockopt  sopt;
+   struct socket   *so;
+   file_t  *fp;
+   unsigned intvalsize, len;
+   int error;
+
+   if (SCARG(uap, val) != NULL) {
+   error = copyin(SCARG(uap, avalsize), , sizeof(valsize));
+   if (error)
+   return error;
+   } else
+   valsize = 0;
+
+   if (valsize > MCLBYTES)
+   return EINVAL;
+
+   if ((error = fd_getsock1(SCARG(uap, s), , )) != 0)
+   return (error);
+
+   sockopt_init(, SCARG(uap, level), SCARG(uap, name), valsize);
+   if (valsize > 0) {
+   error = copyin(SCARG(uap, val), sopt.sopt_data, valsize);
+   if (error)
+   goto out;
+   }
+
+   if (fp->f_flag & FNOSIGPIPE)
+   so->so_options |= SO_NOSIGPIPE;
+   else
+   so->so_options &= ~SO_NOSIGPIPE;
+   error = sogetopt(so, );
+   if (error)
+   goto out;
+
+   if (valsize > 0) {
+   len = min(valsize, sopt.sopt_size);
+   error = copyout(sopt.sopt_data, SCARG(uap, val), len);
+   if (error)
+   goto out;
+
+   error = copyout(, SCARG(uap, avalsize), sizeof(len));
+   if (error)
+   goto out;
+   }
+
+ out:
+   sockopt_destroy();
+   fd_putfile(SCARG(uap, s));
+   return error;
+}
+
 #ifdef PIPE_SOCKETPAIR
 
 int
Index: syscalls.master
===
RCS file: /cvsroot/src/sys/kern/syscalls.master,v
retrieving revision 1.291
diff -u -r1.291 syscalls.master
--- syscalls.master 6 Jan 2018 16:41:23 -   1.291
+++ syscalls.master 6 Mar 2018 00:47:03 -
@@ -986,3 +986,5 @@
siginfo_t *info); }
 482STD { int|sys||clock_getcpuclockid2(idtype_t idtype, \
id_t id, clockid_t *clock_id); }
+483STD RUMP{ int|sys||getsockopt2(int s, int level, int name, \
+   void *val, socklen_t *avalsize); }

Re: getsockopt(2)

[Robert Swindells]

David Holland <dholland-t...@netbsd.org> wrote:
>On Mon, Dec 18, 2017 at 07:21:33PM +, David Holland wrote:
> > On Thu, Dec 07, 2017 at 03:04:32PM +, Robert Swindells wrote:
> >  > I wrote:
> >  >> Does anyone know why we don't use the input 'optlen' parameter to the
> >  >> getsockopt(2) syscall, we do write back to it on return.
> >  >>  [...]
> >  >> 
> >  >> There are also lots of places in sctp_usrreq that want to use it.
> >  >> 
> >  >> I can set it with the following patch (line numbers will be slightly
> >  >> out), but wondered if there was a reason for the current behaviour.
> >  >>  [...]
> >  > 
> >  > Has anyone had any other thoughts on this ?
> >  > 
> >  > I still think that the one line change shown here is correct, it will 
> >  > allocate a buffer that gets filled by the stuff to be copied back to
> >  > userspace.
> > 
> > The man page for getsockopt says [irrelevant stuff]
>
>Oops, I guess I am missing something.

The current code isn't wrong.

In the "get" path, sockopt_set() or sockopt_setmbuf() will allocate a
buffer if needed, most other values are ints and can go in the 4 byte
buffer in the sockopt.

I guess it avoids needing to free the buffer if there is an error while
building up the data to return.

Re: getsockopt(2)

[Robert Swindells]

chris...@astron.com (Christos Zoulas) wrote:
>In article <x7lgi6uze1@ren.fdy2.co.uk>,
>Robert Swindells  <r...@fdy2.co.uk> wrote:
>>Options for NetBSD:
>>
>>  Copy in optval for getsockopt(2):
>>
>>Pro: Allows "get" of IP_IPSEC_POLICY using original KAME API.
>>Con: Diverges from standard. Broken KAME API hasn't been a problem.
>>
>>Wouldn't be too much work to move SCTP operations that were
>>triggered by setsockopt() requests in KAME sources to be triggered
>>by getsockopt() requests instead.
>
>Well, are the semantics though such as to "set" things? While the getsockopt
>call change the state? If yes, perhaps this is not the most intuitive way.
>How many calls are we talking about? I think leaving the source the same
>is a big plus, or coming up with a macro that works for both NetBSD and
>FreeBSD.

There are about 40 options defined by SCTP. I would need to go through
the list to see how many of them were of which type.

There isn't any source shared between FreeBSD and NetBSD anymore, their
stack has diverged a lot from KAME.

>>  Selectively copy out optval for setsockopt(2):
>>
>>Pro: no change to SCTP code.
>>Con: Breaks standard API. Need small change to all other protocols.
>
>I don't like breaking the API, or changing the other protocols. Too intrusive.

I'm not really in favour of this myself, I was just listing all the
alternatives.

>>  Add new syscall to read/write optval:
>>
>>Pro: Doesn't break standard for [set/get]sockopt() API.
>>Con: Doesn't fix IPSEC userland API.
>>
>>Could map onto PRCO_GETOPT within the kernel to minimize changes
>>to protocol code.
>
>We could use ioctl instead too :-)

I would need to check which options are defined to work with
setsockopt(2).

It would be messy within the kernel to have to use setsockopt(2) to set
them and ioctl(2) to get them.

One possible problem is that some of them are defined as taking variable
sized arguments, are there other ioctl(2) requests that do this ?

>>  sctp_peeloff():
>>
>>Add syscall for it:
>>
>>  Pro: Code from KAME builds under -current and is ready to commit.
>>  Con: Adds a new syscall.
>>
>>Map it onto a [set/get/update]sockopt() request:
>>
>>  Pro: Doesn't need a new syscall.
>>  Con: Would need to rewrite implementation. Operation needs to do
>>   file descriptor manipulation which doesn't belong in network
>>   protocol code.
>
>Perhaps map it into ioctl, instead? Ioctl, the swiss knife syscall.

I think this will work.

Re: getsockopt(2)

[Robert Swindells]

chris...@astron.com (Christos Zoulas) wrote:
>In article <x7r2s0vlwx@ren.fdy2.co.uk>,
>Robert Swindells  <r...@fdy2.co.uk> wrote:
>>
>>chris...@astron.com (Christos Zoulas) wrote:
>>>In article <x7tvwxuezy@ren.fdy2.co.uk>,
>>>Robert Swindells  <r...@fdy2.co.uk> wrote:
>>>>
>>>>chris...@astron.com (Christos Zoulas) wrote:
>>>>>In article <x7bmjabmv3@ren.fdy2.co.uk>,
>>>>>
>>>>>So depending on the contents of the sockval we do something different?
>>>>
>>>>FreeBSD does. The calls to copy in or out the data are scattered
>>>>throughout the network stack.
>>>
>>>Is sockval always an int? 
>>
>>Do you mean optname or optval ?
>
>optval.

Ok. No it isn't always an int.

An example of setting something bigger than this would be
IP_IPSEC_POLICY in sys/netinet/ip_output.c line 1206.

The data for accept filters is bigger than an int too.

>>The operation required for setsockopt() is to mostly set things but in
>>certain cases to return an int value that results from setting stuff.
>
>I've lost track of what we are trying to achieve :-( Can you please
>post an example?

There are two categories of extra things that we need to support:

1) Some "get" operations require an extra parameter to select the
correct thing to return.

The "get" side of IP_IPSEC_POLICY is currently wrapped in #ifdef 0
as it won't work without an extra parameter.

SCTP can have multiple endpoints defined for each socket, identified
by an "association" handle, in order to get the correct socket value(s)
the association needs to be passed in as well as the optname that
identifies which type of value is required.

2) In the SCTP code there are extra operations defined that are really
extensions to the socket API, these could be mapped onto new syscalls
but have mostly been implemented by being triggered by setsockopt(2)
requests.

>Also lets compile a table of choices that has:
>
>- description of what's done
>- which os implemented it (if any)
>- pros
>- cons

KAME:

  Added code to sys/kern/uipc_syscalls.c to copy optval contents in and
  out for both setsockopt(2) and getsockopt(2) when built for NetBSD.

  Implements draft of SCTP API.

  Added syscall for sctp_peeloff() operation.

  Other SCTP operations map onto setsockopt(2) requests.

FreeBSD

  Copies optval into kernel as well as out for some getsockopt() and
  setsockopt() requests, code is scattered throughout network stack.

  Manpages don't match implementation, optval shown as 'const' in
  manpage but isn't in kernel source.

  Implements RFC 6458 SCTP API.

  Has sctp_peeloff() as syscall.

  Other SCTP operations map onto setsockopt(2) requests.

Linux:

  Copies optval into kernel as well as out for getsockopt() but only
  for SCTP protocol sockets.
  
  Implements RFC 6458 SCTP API.

  sctp_peeloff() is done through setsockopt() not a syscall.

  Return value of setsockopt(2) used to copy back an int value
  for extra SCTP socket operations:
  <https://sourceforge.net/p/lksctp/mailman/message/18962336/>

  Manpages nearly match implementation, missing is description of
  meaning of positive return value from setsockopt(2) and that
  getsockopt(2) can sometimes copy in optval.

NetBSD:

  Conforms strictly to standard for getsockopt(2) and setsockopt(2).

  Manpages match implementation.

  I suspect that the "get" of IP_IPSEC_POLICY has never worked since we
  imported the IPSEC code.

  Doesn't yet have way to pass extra parameter to "get" socket options.

  Doesn't yet have sctp_peeloff().

  Doesn't have a way of triggering extra SCTP socket operations and
  getting results back to userland.



Options for NetBSD:

  Copy in optval for getsockopt(2):

Pro: Allows "get" of IP_IPSEC_POLICY using original KAME API.
Con: Diverges from standard. Broken KAME API hasn't been a problem.

Wouldn't be too much work to move SCTP operations that were
triggered by setsockopt() requests in KAME sources to be triggered
by getsockopt() requests instead.

  Selectively copy out optval for setsockopt(2):

Pro: no change to SCTP code.
Con: Breaks standard API. Need small change to all other protocols.

  Add new syscall to read/write optval:

Pro: Doesn't break standard for [set/get]sockopt() API.
Con: Doesn't fix IPSEC userland API.

Could map onto PRCO_GETOPT within the kernel to minimize changes
to protocol code.

  sctp_peeloff():

Add syscall for it:

  Pro: Code from KAME builds under -current and is ready to commit.
  Con: Adds a new syscall.

Map it onto a [set/get/update]sockopt() request:

  Pro: Doesn't need a new syscall.
  Con: Would need to rewrite implementation. Operation needs to do
   file descriptor manipulation which doesn't belong in network
   protocol code.

Re: getsockopt(2)

[Robert Swindells]

chris...@astron.com (Christos Zoulas) wrote:
>In article <x7tvwxuezy@ren.fdy2.co.uk>,
>Robert Swindells  <r...@fdy2.co.uk> wrote:
>>
>>chris...@astron.com (Christos Zoulas) wrote:
>>>In article <x7bmjabmv3@ren.fdy2.co.uk>,
>>>
>>>So depending on the contents of the sockval we do something different?
>>
>>FreeBSD does. The calls to copy in or out the data are scattered
>>throughout the network stack.
>
>Is sockval always an int? 

Do you mean optname or optval ?

>>Linux seems to cheat and make use of the fact that their errors are
>>negative to return a positive integer word value from
>>setsockopt(). Their implementation of getsockopt() copies in and out.
>
>Hmm, that is not what the man page claims :-)

Linux doesn't really do man pages though, I looked at the source. The
FreeBSD man page is wrong too.

There is a thread on lkml describing what Linux did.

>>I would still prefer to change both getsockopt(2) and setsockopt(2).
>>
>>I would make getsockopt always copy in the supplied optval argument.
>
>Well, it has to copyout, so presumably that won't break existing code.

I have run a kernel for a while with this change to getsockopt() and
it seemed fine.

>>For setsockopt, the protocol code can update sopt_size to indicate the
>>amount of data to be copied back. I would add a line to the PRCO_SETOPT
>>handler in most protocols to set sopt_size to 0 so that nothing was
>>copied back.
>
>That could break things; grepping for sopt_size finds many checks for it.
>There is also sockopt_setmbuf that can potentially allocate larger than
>MCLBYTES socket option?

I meant that I would set sopt_size to zero after all the processing
of the input data has been finished.

The only place that I could see mbufs being used was in ipsec, which
doesn't work because it needs these changes too.

>>The syscall definition for setsockopt() would need to be changed to
>>remove the 'const' from the optval argument.
>
>That is arguably the worst part of the change. The API for it is part of
>the standard. Well, we can go the linux way and make getsockopt read and
>write, but that makes me cringe. Perhaps adding an updatesockopt() is better?

It is the FreeBSD way as well.

The operation required for getsockopt() isn't really *updating* the
socket options, it is more "get with an extra parameter".

The operation required for setsockopt() is to mostly set things but in
certain cases to return an int value that results from setting stuff.

Re: getsockopt(2)

[Robert Swindells]

chris...@astron.com (Christos Zoulas) wrote:
>In article <x7bmjabmv3@ren.fdy2.co.uk>,
>Robert Swindells  <r...@fdy2.co.uk> wrote:
>>
>>I wrote:
>>>Does anyone know why we don't use the input 'optlen' parameter to the
>>>getsockopt(2) syscall, we do write back to it on return.
>>>
>>>In ip_output() there is this, which suggests that someone had come
>>>across this before.
>>>
>>>#if 0   /* defined(IPSEC) */
>>>case IP_IPSEC_POLICY:
>>>{
>>>struct mbuf *m = NULL;
>>>
>>>/* XXX this will return EINVAL as sopt is empty */
>>>error = ipsec4_get_policy(inp, sopt->sopt_data,
>>>sopt->sopt_size, );
>>>if (error == 0)
>>>error = sockopt_setmbuf(sopt, m);
>>>break;
>>>}   
>>>#endif /*IPSEC*/  
>>>
>>>There are also lots of places in sctp_usrreq that want to use it.
>>>
>>>I can set it with the following patch (line numbers will be slightly
>>>out), but wondered if there was a reason for the current behaviour.
>>>
>>>Index: uipc_syscalls.c
>>>===
>>>RCS file: /cvsroot/src/sys/kern/uipc_syscalls.c,v
>>>retrieving revision 1.187
>>>diff -u -r1.187 uipc_syscalls.c
>>>--- uipc_syscalls.c  20 Jun 2017 20:34:49 -  1.187
>>>+++ uipc_syscalls.c  14 Oct 2017 21:33:09 -
>>>@@ -1235,7 +1240,7 @@
>>> if ((error = fd_getsock1(SCARG(uap, s), , )) != 0)
>>> return (error);
>>> 
>>>-sockopt_init(, SCARG(uap, level), SCARG(uap, name), 0);
>>>+sockopt_init(, SCARG(uap, level), SCARG(uap, name), valsize);
>>> 
>>> if (fp->f_flag & FNOSIGPIPE)
>>> so->so_options |= SO_NOSIGPIPE;
>>
>>Has anyone had any other thoughts on this ?
>
>Yes, if you don't protect valsize against MCLBYTES like setsockopt does,
>it can be used to DoS kernel. Otherwise is can be done. Is 2K enough?

Yes, 2K would be enough. Have added the check in my tree.

>>I'm thinking of adding an extra socket option, maybe SO_PARAM, that you
>>would use with setsockopt(2) to set a selector to be used by a following
>>getsockopt(2) call.
>
>This would require some state keeping in the kernel and might not be
>reliable.

I know, it is the only alternative that I can think of to changing
setsockopt(2).

>>This wouldn't fix the IPSEC usage without changing userland though.
>>
>>The alternative is to make both setsockopt(2) and getsockopt(2)
>>bidirectional.
>
>So depending on the contents of the sockval we do something different?

FreeBSD does. The calls to copy in or out the data are scattered
throughout the network stack.

Linux seems to cheat and make use of the fact that their errors are
negative to return a positive integer word value from
setsockopt(). Their implementation of getsockopt() copies in and out.

I would still prefer to change both getsockopt(2) and setsockopt(2).

I would make getsockopt always copy in the supplied optval argument.

For setsockopt, the protocol code can update sopt_size to indicate the
amount of data to be copied back. I would add a line to the PRCO_SETOPT
handler in most protocols to set sopt_size to 0 so that nothing was
copied back.

The syscall definition for setsockopt() would need to be changed to
remove the 'const' from the optval argument.

>>I haven't checked in the userland implementation of sctp_opt_info(3)
>>yet. I took the one from FreeBSD but can modify it to work with a
>>different API.
>
>Ok.

This still requires an alternative API to use. I haven't found an
example of an OS that hides one in its version of sctp_opt_info().

Re: getsockopt(2)

[Robert Swindells]

I wrote:
>Does anyone know why we don't use the input 'optlen' parameter to the
>getsockopt(2) syscall, we do write back to it on return.
>
>In ip_output() there is this, which suggests that someone had come
>across this before.
>
>#if 0   /* defined(IPSEC) */
>case IP_IPSEC_POLICY:
>{
>struct mbuf *m = NULL;
>
>/* XXX this will return EINVAL as sopt is empty */
>error = ipsec4_get_policy(inp, sopt->sopt_data,
>sopt->sopt_size, );
>if (error == 0)
>error = sockopt_setmbuf(sopt, m);
>break;
>}   
>#endif /*IPSEC*/  
>
>There are also lots of places in sctp_usrreq that want to use it.
>
>I can set it with the following patch (line numbers will be slightly
>out), but wondered if there was a reason for the current behaviour.
>
>Index: uipc_syscalls.c
>===
>RCS file: /cvsroot/src/sys/kern/uipc_syscalls.c,v
>retrieving revision 1.187
>diff -u -r1.187 uipc_syscalls.c
>--- uipc_syscalls.c20 Jun 2017 20:34:49 -  1.187
>+++ uipc_syscalls.c14 Oct 2017 21:33:09 -
>@@ -1235,7 +1240,7 @@
>   if ((error = fd_getsock1(SCARG(uap, s), , )) != 0)
>   return (error);
> 
>-  sockopt_init(, SCARG(uap, level), SCARG(uap, name), 0);
>+  sockopt_init(, SCARG(uap, level), SCARG(uap, name), valsize);
> 
>   if (fp->f_flag & FNOSIGPIPE)
>   so->so_options |= SO_NOSIGPIPE;

Has anyone had any other thoughts on this ?

I still think that the one line change shown here is correct, it will 
allocate a buffer that gets filled by the stuff to be copied back to
userspace.

The SCTP API that is defined in RFC 6458 does allow for the case where
getsockopt(2) and setsockopt(2) are both unidirectional. The API defines
a wrapper function sctp_opt_info(3) that can hide whatever mechanism
is used to pass into the kernel an extra parameter to be used to select
what is returned by getsockopt(2).

I'm thinking of adding an extra socket option, maybe SO_PARAM, that you
would use with setsockopt(2) to set a selector to be used by a following
getsockopt(2) call.

This wouldn't fix the IPSEC usage without changing userland though.

The alternative is to make both setsockopt(2) and getsockopt(2)
bidirectional.

I haven't checked in the userland implementation of sctp_opt_info(3)
yet. I took the one from FreeBSD but can modify it to work with a
different API.

Re: getsockopt(2)

[Robert Swindells]

chris...@astron.com (Christos Zoulas) wrote:
>In article <x7r2u3inin@ren.fdy2.co.uk>,
>Robert Swindells  <r...@fdy2.co.uk> wrote:
>>
>>chris...@astron.com (Christos Zoulas) wrote:
>>>In article <x7wp3xi6py@ren.fdy2.co.uk>,
>>>Robert Swindells  <r...@fdy2.co.uk> wrote:
>>>>
>>>>I wrote:
>>>>>Does anyone know why we don't use the input 'optlen' parameter to the
>>>>>getsockopt(2) syscall, we do write back to it on return.
>>
>>[snip]
>>
>>>Neither FreeBSD or OpenBSD copyin the value, but I think it is ok to
>>>do so if it is useful to read the input to deduce the output. But that
>>>would make the call asymetric, so let's examine the examples where this
>>>is useful first.
>>
>>FreeBSD does copyin the value, but the code to do it is scattered around
>>the kernel, search for sooptcopyin() in their tree.
>
>Yes, aren't most of the in the sosetopt paths? I am looking for the sogetopt
>paths... I have not looked carefully to see if there are any.

It is done for TCP_CCALGOOPT and for all the SCTP options.

I had reused the FreeBSD userland for SCTP, I was trying to test it
before committing the final bits. I would prefer not to have to
redesign it.

Re: getsockopt(2)

[Robert Swindells]

chris...@astron.com (Christos Zoulas) wrote:
>In article <x7wp3xi6py@ren.fdy2.co.uk>,
>Robert Swindells  <r...@fdy2.co.uk> wrote:
>>
>>I wrote:
>>>Does anyone know why we don't use the input 'optlen' parameter to the
>>>getsockopt(2) syscall, we do write back to it on return.

[snip]

>Neither FreeBSD or OpenBSD copyin the value, but I think it is ok to
>do so if it is useful to read the input to deduce the output. But that
>would make the call asymetric, so let's examine the examples where this
>is useful first.

FreeBSD does copyin the value, but the code to do it is scattered around
the kernel, search for sooptcopyin() in their tree.

Robert Swindells

Re: getsockopt(2)

[Robert Swindells]

I wrote:
>Does anyone know why we don't use the input 'optlen' parameter to the
>getsockopt(2) syscall, we do write back to it on return.
>
>In ip_output() there is this, which suggests that someone had come
>across this before.
>
>#if 0   /* defined(IPSEC) */
>case IP_IPSEC_POLICY:
>{
>struct mbuf *m = NULL;
>
>/* XXX this will return EINVAL as sopt is empty */
>error = ipsec4_get_policy(inp, sopt->sopt_data,
>sopt->sopt_size, );
>if (error == 0)
>error = sockopt_setmbuf(sopt, m);
>break;
>}   
>#endif /*IPSEC*/  
>
>There are also lots of places in sctp_usrreq that want to use it.
>
>I can set it with the following patch (line numbers will be slightly
>out), but wondered if there was a reason for the current behaviour.

Version 2 of the patch is below, the uses of getsockopt(2) by IPSEC and
SCTP expect that the optval data is copied into the kernel and back out
again by the syscall.

It looks like it was broken by this commit:



Index: uipc_syscalls.c
===
RCS file: /cvsroot/src/sys/kern/uipc_syscalls.c,v
retrieving revision 1.187
diff -u -r1.187 uipc_syscalls.c
--- uipc_syscalls.c 20 Jun 2017 20:34:49 -  1.187
+++ uipc_syscalls.c 14 Oct 2017 22:24:15 -
@@ -1235,7 +1240,13 @@
if ((error = fd_getsock1(SCARG(uap, s), , )) != 0)
return (error);
 
-   sockopt_init(, SCARG(uap, level), SCARG(uap, name), 0);
+   sockopt_init(, SCARG(uap, level), SCARG(uap, name), valsize);
+
+   if (valsize > 0) {
+   error = copyin(SCARG(uap, val), sopt.sopt_data, valsize);
+   if (error)
+   goto out;
+   }
 
if (fp->f_flag & FNOSIGPIPE)
so->so_options |= SO_NOSIGPIPE;

getsockopt(2)

[Robert Swindells]

Does anyone know why we don't use the input 'optlen' parameter to the
getsockopt(2) syscall, we do write back to it on return.

In ip_output() there is this, which suggests that someone had come
across this before.

#if 0   /* defined(IPSEC) */
case IP_IPSEC_POLICY:
{
struct mbuf *m = NULL;

/* XXX this will return EINVAL as sopt is empty */
error = ipsec4_get_policy(inp, sopt->sopt_data,
sopt->sopt_size, );
if (error == 0)
error = sockopt_setmbuf(sopt, m);
break;
}   
#endif /*IPSEC*/  

There are also lots of places in sctp_usrreq that want to use it.

I can set it with the following patch (line numbers will be slightly
out), but wondered if there was a reason for the current behaviour.

Index: uipc_syscalls.c
===
RCS file: /cvsroot/src/sys/kern/uipc_syscalls.c,v
retrieving revision 1.187
diff -u -r1.187 uipc_syscalls.c
--- uipc_syscalls.c 20 Jun 2017 20:34:49 -  1.187
+++ uipc_syscalls.c 14 Oct 2017 21:33:09 -
@@ -1235,7 +1240,7 @@
if ((error = fd_getsock1(SCARG(uap, s), , )) != 0)
return (error);
 
-   sockopt_init(, SCARG(uap, level), SCARG(uap, name), 0);
+   sockopt_init(, SCARG(uap, level), SCARG(uap, name), valsize);
 
if (fp->f_flag & FNOSIGPIPE)
so->so_options |= SO_NOSIGPIPE;

Re: max open files

[Robert Swindells]

co...@sdf.org wrote:
>this number is way too easy to hit just linking things in pkgsrc. can we
>raise it? things fail hard when it is hit.
>
>ive seen people say 'when your build dies, restart it with MAKE_JOBS=1
>so it doesn't link in parallel'.

I saw this for the first time today too.

Maybe something has started leaking file descriptors.

Re: Linux procfs

[Robert Swindells]

chris...@astron.com (Christos Zoulas) wrote:
>In article <x7efu7wmk2@ren.fdy2.co.uk>,
>Robert Swindells  <r...@fdy2.co.uk> wrote:
>>
>>matthew green <m...@eterna.com.au> wrote:
>>>Robert Swindells writes:
>>>> 
>>>> Do we care about keeping all the Linux procfs code in
>>>> sys/miscfs/proc/procfs_linux.c ?
>>>> 
>>>> Some Linux applications have started grovelling in /proc/self/status to
>>>> read various values.
>>>> 
>>>> I have added some Linux emulation specific code to procfs_status.c but
>>>> can move it if people object.
>>>
>>>what are the extensions?  maybe we want them for netbsd anyway?
>>
>>It is mostly just changing the format of what is printed.
>>
>>I haven't replicated everything that is in the procfs node under Linux,
>>just enough to get one application working (Xilinx Vivado). One of the
>>lines is used by the HTML browser in JavaFX though so it will probably
>>be needed elsewhere.
>>
>>>can the code be structured such that most of it is in procfs_linux.c
>>>and called to from procfs_status.c?
>>
>>I think it would be more a case of moving the whole contents of
>>procfs_status.c to procfs_linux.c
>>
>>The diff is below.
>
>The same diff ignoring whitespace becomes:

[snip] 

>Which means that it would be better to refactor this code into separate
>routines (linux specific and netbsd-specific). The function is already
>too long and complicated.

Split up into two functions:

Index: procfs_status.c
===
RCS file: /cvsroot/src/sys/miscfs/procfs/procfs_status.c,v
retrieving revision 1.37
diff -u -r1.37 procfs_status.c
--- procfs_status.c 14 Nov 2016 08:55:51 -  1.37
+++ procfs_status.c 28 Sep 2017 12:20:29 -
@@ -88,13 +88,8 @@
 
 #include 
 
-int
-procfs_dostatus(
-struct lwp *curl,
-struct lwp *l,
-struct pfsnode *pfs,
-struct uio *uio
-)
+static int
+procfs_status_netbsd(struct lwp *l, struct uio *uio)
 {
struct session *sess;
struct tty *tp;
@@ -107,8 +102,6 @@
char psbuf[256+MAXHOSTNAMELEN]; /* XXX - conservative */
uint16_t ngroups;
 
-   if (uio->uio_rw != UIO_READ)
-   return (EOPNOTSUPP);
 
mutex_enter(proc_lock);
mutex_enter(p->p_lock);
@@ -183,3 +176,63 @@
 
return (uiomove_frombuf(psbuf, ps - psbuf, uio));
 }
+
+static int
+procfs_status_linux(struct lwp *l, struct uio *uio)
+{
+   kauth_cred_t cr;
+   struct proc *p = l->l_proc;
+   char *ps;
+   int pid, ppid;
+   u_int i;
+   char psbuf[256+MAXHOSTNAMELEN]; /* XXX - conservative */
+   uint16_t ngroups;
+
+   mutex_enter(proc_lock);
+   mutex_enter(p->p_lock);
+
+   pid = p->p_pid;
+   ppid = p->p_ppid;
+
+   ps = psbuf;
+   ps += snprintf(ps, sizeof(psbuf), "Name:\t%s\n", p->p_comm);
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), "Pid:\t%d\n", pid);
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), "PPid:\t%d\n", ppid);
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), "TracerPid:\t%d\n", 0);
+
+   cr = p->p_cred;
+   ngroups = kauth_cred_ngroups(cr);
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), "Groups:\t");
+   for (i = 0; i < ngroups; i++)
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), "%d ",
+   kauth_cred_group(cr, i));
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), "\n");
+
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf),
+   "VmPeak:\t%8" PRIu64 " kB\n", p->p_rlimit[RLIMIT_DATA].rlim_cur / 
1024);
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf),
+   "VmSize:\t%8" PRIu64 " kB\n", p->p_rlimit[RLIMIT_DATA].rlim_cur / 
1024);
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf),
+   "VmRSS:\t%8" PRIu64 " kB\n", p->p_rlimit[RLIMIT_RSS].rlim_cur / 
1024);
+
+   mutex_exit(p->p_lock);
+   mutex_exit(proc_lock);
+
+   return (uiomove_frombuf(psbuf, ps - psbuf, uio));
+}
+
+int
+procfs_dostatus(struct lwp *curl, struct lwp *l, struct pfsnode *pfs,
+struct uio *uio)
+{
+   const char *emulname = curlwp->l_proc->p_emul->e_name;
+
+   if (uio->uio_rw != UIO_READ)
+   return (EOPNOTSUPP);
+
+   if (strncmp(emulname, "linux", 5) == 0) {
+   return procfs_status_linux(l, uio);
+   } else {
+   return procfs_status_netbsd(l, uio);
+   }
+}

Re: Proposal: Disable autoload of compat_xyz modules

[Robert Swindells]

Taylor R Campbell  wrote:
>(The code will also continue to be compile-tested as non-module via
>the ALL kernels.)

Maybe we need an ALL kernel for sparc64.

Re: Proposal: Disable autoload of compat_xyz modules

[Robert Swindells]

m...@netbsd.org wrote:
On Mon, Jul 31, 2017 at 09:39:42PM +, Taylor R Campbell wrote:
>> P.S.  The old-NetBSD, a.out, and 32-bit compat modules may be broken
>> too, and are probably not automatically tested either, but are more
>> likely to be manually tested and I'm not addressing them right now.
>> These are:
>
>netbsd/mips64 runs a 64bit kernel and full 32bit userland, so
>>compat_netbsd32 is tested very heavily on it.

Running NetBSD/sparc on 64bit hardware works like this too.

Re: Proposal: Disable autoload of compat_xyz modules

[Robert Swindells]

Taylor R Campbell  wrote:
>> Date: Tue, 1 Aug 2017 00:45:24 +0200
>> From: Kamil Rytarowski 
>> 
>> I use both linux and linux32 ones.
>
>Can you argue that these and the others you listed should be
>automatically enabled by default, and that having to modload them
>would be too much of a burden?
>
>Can you say who maintains them, or volunteer to maintain them,
>including writing automatic tests with sample binaries that others can
>use to test security fixes?
>
>I want to learn more than just who uses these -- I want to estimate
>the negative impact of disabling them by default, and what effort we
>have available to make sure they continue to work reliably.

I use linux, linux32 and netbsd32 to run fairly big applications that
I think test out a good spread of features.

The Xilinx FPGA tools make use of compat_linux and compat_linux32. I
have an uncommitted patch to procfs to make the latest version work.

I regularly run CMUCL on amd64 using compat_netbsd32.

Re: Can't compile NetBSD kernel in Virtual Box due to assym.h error

[Robert Swindells]

Devin Steffler  wrote:
>I'm trying to compile a NetBSD kernel in a Virtual Box but I'm getting
>an error. I believe that what I am trying to do is reasonable and should
>work "out of the box". Let me know if this is a false assumption (for
>example, if NetBSD is known not to compile in a Virtual Box for some
>reason).

[snip]

>Steps to reproduce:
>- Download and install Oracle VM Virtual Box
>- Create a new virtual machine and add the image NetBSD-7.1-amd64.iso to
>its storage tree

[snip]

>I am executing these commands after getting the syssrc.tgz file:
>cd /
>tar zxf /root/syssrc.tgz
>cd /usr/src/sys/arch/i386/conf/
>cp GENERIC MYKERNEL
>config MYKERNEL
>cd ../compile/MYKERNEL
>make depend

You are running NetBSD/amd64 but trying to build a NetBSD/i386 kernel
using the native tools, that won't work.

Re: Linux procfs

[Robert Swindells]

matthew green <m...@eterna.com.au> wrote:
>Robert Swindells writes:
>> 
>> Do we care about keeping all the Linux procfs code in
>> sys/miscfs/proc/procfs_linux.c ?
>> 
>> Some Linux applications have started grovelling in /proc/self/status to
>> read various values.
>> 
>> I have added some Linux emulation specific code to procfs_status.c but
>> can move it if people object.
>
>what are the extensions?  maybe we want them for netbsd anyway?

It is mostly just changing the format of what is printed.

I haven't replicated everything that is in the procfs node under Linux,
just enough to get one application working (Xilinx Vivado). One of the
lines is used by the HTML browser in JavaFX though so it will probably
be needed elsewhere.

>can the code be structured such that most of it is in procfs_linux.c
>and called to from procfs_status.c?

I think it would be more a case of moving the whole contents of
procfs_status.c to procfs_linux.c

The diff is below.

Index: procfs_status.c
===
RCS file: /cvsroot/src/sys/miscfs/procfs/procfs_status.c,v
retrieving revision 1.37
diff -u -r1.37 procfs_status.c
--- procfs_status.c 14 Nov 2016 08:55:51 -  1.37
+++ procfs_status.c 26 Jun 2017 01:36:05 -
@@ -102,6 +102,7 @@
struct proc *p = l->l_proc;
char *ps;
const char *sep;
+   const char *emulname = curlwp->l_proc->p_emul->e_name;
int pid, ppid, pgid, sid;
u_int i;
char psbuf[256+MAXHOSTNAMELEN]; /* XXX - conservative */
@@ -119,65 +120,87 @@
sess = p->p_pgrp->pg_session;
sid = sess->s_sid;
 
-/* comm pid ppid pgid sid maj,min ctty,sldr start ut st wmsg uid gid groups 
... */
-
ps = psbuf;
-   memcpy(ps, p->p_comm, MAXCOMLEN);
-   ps[MAXCOMLEN] = '\0';
-   ps += strlen(ps);
-   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), " %d %d %d %d ",
-   pid, ppid, pgid, sid);
-
-   if ((p->p_lflag & PL_CONTROLT) && (tp = sess->s_ttyp))
-   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), "%llu,%llu ",
-   (unsigned long long)major(tp->t_dev),
-   (unsigned long long)minor(tp->t_dev));
-   else
-   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), "%d,%d ",
-   -1, -1);
-
-   sep = "";
-   if (sess->s_ttyvp) {
-   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), "%sctty", sep);
-   sep = ",";
-   }
-   if (SESS_LEADER(p)) {
-   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), "%ssldr", sep);
-   sep = ",";
-   }
-   if (*sep != ',')
-   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), "noflags");
-
-   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), " %lld,%ld",
-   (long long)p->p_stats->p_start.tv_sec,
-   (long)p->p_stats->p_start.tv_usec);
-
-   {
-   struct timeval ut, st;
+   if (strncmp(emulname, "linux", 5) == 0) {
+   ps += snprintf(ps, sizeof(psbuf), "Name:\t%s\n", p->p_comm);
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), "Pid:\t%d\n", 
pid);
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), "PPid:\t%d\n", 
ppid);
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), 
"TracerPid:\t%d\n", 0);
+
+   cr = p->p_cred;
+   ngroups = kauth_cred_ngroups(cr);
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), "Groups:\t");
+   for (i = 0; i < ngroups; i++)
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), "%d ",
+   kauth_cred_group(cr, i));
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), "\n");
 
-   calcru(p, , , (void *) 0, NULL);
ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf),
-   " %lld,%ld %lld,%ld", (long long)ut.tv_sec,
-   (long)ut.tv_usec, (long long)st.tv_sec, (long)st.tv_usec);
-   }
+   "VmPeak:\t%8lu kB\n", p->p_rlimit[RLIMIT_DATA].rlim_cur / 
1024);
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf),
+   "VmSize:\t%8lu kB\n", p->p_rlimit[RLIMIT_DATA].rlim_cur / 
1024);
+   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf),
+   "VmRSS:\t%8lu kB\n", p->p_rlimit[RLIMIT_RSS].rlim_cur / 
1024);
 
-   lwp_lock(l);
-   ps += snprintf(ps, sizeof(psbuf) - (ps - psbuf), " %s",
-   (l->l_wchan && l->l_wmesg) ? l->l_wmes

Linux procfs

[Robert Swindells]

Do we care about keeping all the Linux procfs code in
sys/miscfs/proc/procfs_linux.c ?

Some Linux applications have started grovelling in /proc/self/status to
read various values.

I have added some Linux emulation specific code to procfs_status.c but
can move it if people object.

Robert Swindells

Re: ARM pmap

[Robert Swindells]

matthew green <m...@eterna.com.au> wrote:
>Robert Swindells writes:
>> 
>> Is there anything in the way that uvm is used on ARM that would break
>> being able to replace executables that are in use ?
>> 
>> Trying to update a running system on a CubieTruck causes garbage to be
>> written to /sbin/init and it fails to start up on reboot.
>> 
>> I first saw this a few months ago but it did work fine before that.
>
>how are you doing the update?  cp(1) will break stuff, but pax(1) won't.

Was doing "find . -print | cpio -pdmu", works on every other architecture.

Re: route(4): Adding ROUTE_MSGFILTER socket option

[Robert Swindells]

Robert Elz <k...@munnari.oz.au> wrote:
>Date:Wed, 5 Apr 2017 11:00:35 +0100
>From:Roy Marples <r...@marples.name>
>Message-ID:  <aafd749a-2883-6aef-568f-fc8b6db26...@marples.name>
>
>  | Comments welcome!
>
>Looks mostly good to me, with a caveat, and the same / a similar mechanism
>would also be useful for the mobility socket (which is a clone of the
>routing socket) if we ever add the Mobile IP code - and could probably be
>used for generic raw sockets (aka ping and such) with a very similar
>filter function.

I have got the Kame Mobile IP code in my tree, what kind of mechanism
do you think needs to be added to better support it ?

The Mobile IP userland could make use of this patch to reduce the amount
of times that it is woken up by routing socket changes other than
RTM_CHGADDR.

Robert Swindells

Re: USB slave

[Robert Swindells]

On Thu, March 9, 2017 4:38 am, Hiroyuki Bessho wrote:
> At Mon, 6 Mar 2017 17:33:51 +0100,
> Manuel Bouyer wrote:
>>
>> On Mon, Mar 06, 2017 at 04:26:48PM +, Emmanuel Dreyfus wrote:
>> > Hello
>> >
>> > Is it possible to use a USB port as a USB slave? I would like to
>> > make it act as a keyboard to output some data to another machine.
>> >
>> > The usb(4) man page suggests the NetBSD kernel can only act as a
>> > USB master. But perhaps there is a hardware limitation there?
>>
>> Yes, the hardware for USB master or slave are differents.
>> To allow a device to act either as master of slave USB OTG has been
>> specified.
>> Some SoC platforms have such controllers.
>> But at this time NetBSD supports OTG only in master mode.
>> Supporting slave mode would require a non-trivial amount of work on the
>> USB
>> stack.
>
>   I have a project to support slave-side USB in NetBSD kernel.  I made
> an interim report about the project at AsiaBSDCon 2016.  I hope I can
> bring up patches for proposal in a few months.

Isn't there already a slave side USB driver for emulated ethernet for
StrongARM/PXA devices ?

Re: SOSEND_LOAN problems in MIPS

[Robert Swindells]

co...@sdf.org wrote:
>in emulating pmax with gxemul I had trouble using:
>  cat somefile | command
>
>when somefile is bigger than 4096 bytes.
>it shows no output when with a slightly smaller file, it would.
>
>using options SOSEND_NO_LOAN 'fixes' it.
>seems many MIPS configs have this option.
>
>what is a good way to figure out what is wrong?

You can find what the option does using grep(1). Use the search button
on the mailing list archives to see if anyone else has had a similar
problem.

It looks to me as if the only place that it is used is in
sys/kern/uipc_socket.c.

The behaviour that is enabled by the option is also enabled if
MULTIPROCESSOR is true so I would guess that this code path is
followed on most NetBSD systems in use today.

The mailing list archives suggest that some ports have had pmap bugs
in the past that were triggered if the SOSEND_NO_LOAN option wasn't
enabled.

It could also be that as the kernel size has grown over time the
amount of free memory on a PMAX isn't large enough. How have you
configured gxemul ?

It would probably also help to know where the file that you read
using cat was stored, was it read over NFS ?

Re: kernel symbol redefined messages

[Robert Swindells]

Paul Goyette <p...@whooppee.com> wrote:
>On Mon, 6 Jun 2016, Robert Swindells wrote:
>
>>
>> Paul Goyette <p...@whooppee.com> wrote:
>>> With a kernel built from today's sources (updated via anoncvs on
>>> 2016-06-05 at 13:29:32 UTC), I'm seeing the following messages when
>>> loading the iic and bpf modules, resulting in load failure:
>>
>> [snip]
>>
>> Why doesn't the system think that the iic and bpf modules are already
>> loaded ?
>
>It correctly thinks/knows that they aren't already loaded, because these 
>modules don't exist in my custom kernel.

You wrote that the iic functions were already linked into the kernel,
why isn't the module for them already registered too ?

Re: kernel symbol redefined messages

[Robert Swindells]

Paul Goyette  wrote:
>With a kernel built from today's sources (updated via anoncvs on 
>2016-06-05 at 13:29:32 UTC), I'm seeing the following messages when 
>loading the iic and bpf modules, resulting in load failure:

[snip]

Why doesn't the system think that the iic and bpf modules are already
loaded ?

Re: device-major question

[Robert Swindells]

Nick Hudson wrote:
>On 05/11/16 11:52, Kimihiro Nonaka wrote:
>> 2016-05-11 15:41 GMT+09:00 Nick Hudson<sk...@netbsd.org>:
>>
>>> I'd be happy (as a tegra owner/user) to move hdmicec to 206. I don't think
>>> hdmicec is use anywhere else yet.
>> char 206 is already used by seeprom.
>>
>> - sys/conf/majors
>> device-major seeprom char 206 seeprom
>> -
>
>heh, no idea where I got 206 from. I meant 210 - see diff.

char 210 is wsdisplay, and is in the range shown as reserved for ws
devices in the comments.

Why not leave the hdmicec line below the "reserved" comments and use
340 for it ?

Robert Swindells

UVM wait states

[Robert Swindells]

Would there be any objection to the following patch, it makes it easier
to see in top(1) which thing a process is waiting for.

Robert Swindells

Index: uvm_vnode.c
===
RCS file: /cvsroot/src/sys/uvm/uvm_vnode.c,v
retrieving revision 1.102
diff -u -r1.102 uvm_vnode.c
--- uvm_vnode.c 6 Dec 2015 09:38:54 -   1.102
+++ uvm_vnode.c 24 Feb 2016 00:00:41 -
@@ -265,7 +265,7 @@
return 0;
}
mutex_exit(uobj->vmobjlock);
-   uvm_wait("uvn_fp1");
+   uvm_wait("uvnfp1");
mutex_enter(uobj->vmobjlock);
continue;
}
@@ -287,7 +287,7 @@
UVMHIST_LOG(ubchist, "wait %p (color %u)", pg,
VM_PGCOLOR_BUCKET(pg), 0,0);
UVM_UNLOCK_AND_WAIT(pg, uobj->vmobjlock, 0,
-   "uvn_fp2", 0);
+   "uvnfp2", 0);
mutex_enter(uobj->vmobjlock);
continue;
}

Re: Simplify bridge(4)

[Robert Swindells]

Ryota Ozaki wrote:
>On Thu, Feb 11, 2016 at 3:17 AM, Mouse <mo...@rodents-montreal.org> wrote:
>>> [J]ust wondering if we are going to see vether(4) anytime soon.
>>
>> How would this vether differ from the existing tap?  Presumably I'm
>> just missing something
>
>dhcpcd didn't work well with bridge(4) and tap(4) didn't help that.
>vether(4) would help that. We may be able to address the issue by
>fixing bridge or tap but I have no idea for now.

I have a theory for why this happens.

I have a local change to bridge(4) in my tree that explicitly adds the
MAC address for each member interface rather than adding it lazily the
first time it is seen in a packet.

Robert Swindells

compat linux futex problem

[Robert Swindells]

I'm trying to run a fairly large Linux application that is a mixture of
Java and native code, it spawns off several threads but all of them
end up waiting on futex and not using any cpu time.

I have run it with DEBUG_LINUX_FUTEX enabled which produces a *lot* of
debug, anybody got any idea what to look for in it ?

Robert Swindells

Re: New Syscall

[Robert Swindells]

Taylor R Campbell wrote:
>   Date: Wed, 14 Oct 2015 22:55:41 +0100 (BST)
>   From: Robert Swindells <r...@fdy2.co.uk>
>
>   The syscall is sctp_peeloff().
>
>Hmm...  Introducing a protocol-specific syscall doesn't strike me as a
>great design.  I can imagine wanting to do something similar with,
>e.g., minimalt, if we ever had that in-kernel.
>
>If we have to have something protocol-specific, an ioctl would work
>just as well, and use up a somewhat less scarce resource.

The code is from KAME, I didn't write it from scratch, FreeBSD also has
a syscall for it.

Linux uses getsockopt() for this, which seems wrong to me as you are
not just reading a setting when you make the call.

Robert Swindells

Re: NFS writes being corrupted?

[Robert Swindells]

David Holland wrote:
On Mon, Aug 03, 2015 at 02:51:37PM -0700, Jeff Rizzo wrote:
  I need to look deeper, but a quick test writing lines of
  ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
  
  Shows that corruption starts when the file is exactly 65536 bytes long
  (with an 8192 byte page size), with anything that size or longer getting
  corrupted.  It seems to be randomly garbled - same size, same bytes, but
  shuffled around.  When I was narrowing it down, I sometimes saw random
  corruption inserted at larger file sizes - at one point I saw short strings
  of NUL and the string posix2_upe (which would appear to be a symbol?)
  inserted at seemingly-random spots.

Does that size vary with the NFS block size?

Also is it using UDP or TCP ?

The symptoms make me think of scrambled mbufs, if anything...

My guess is that the panics that wiz and I saw in the checksum code
on amd64 were also due to scrambled mbufs.

My cubietruck seems fine using awge(4), I have built a fair number of
packages over NFS recently.

Robert Swindells

Re: Linux ioctl emulation

[Robert Swindells]

Nicolas Joly wrote:
On Fri, Jul 10, 2015 at 09:21:25PM +0100, Robert Swindells wrote:
 
 I'm getting a panic in compat_ifioctl() in if_43.c when a linux binary
 makes an ioctl(fd, SIOCGIFBRDADDR, data ) call.
 
 In this code at the end of the function oifr is NULL.
 
 if (cmd != ocmd)
 ifreqn2o(oifr, ifr);

Should be fixed, please test.

Yes, works now. Thanks.

Robert Swindells

Linux ioctl emulation

[Robert Swindells]

I'm getting a panic in compat_ifioctl() in if_43.c when a linux binary
makes an ioctl(fd, SIOCGIFBRDADDR, data ) call.

In this code at the end of the function oifr is NULL.

if (cmd != ocmd)
ifreqn2o(oifr, ifr);

Robert Swindells

Re: Groff

[Robert Swindells]

Johnny Billquist b...@softjar.se wrote:
On 2015-06-04 09:43, Matt Thomas wrote:

 On Jun 3, 2015, at 10:05 PM, Aleksej Saushev a...@inbox.ru wrote:

 Just in case you don't know, nearly any user has libxml2 and libxslt
 installed anyway.

 None of my systems do.

I thought Aleksej was joking... The suggestion to get rid of groff 
because it needed C++, and replace it with XML, a full blown web 
browser, and god know how many libraries seemed like the ultimate joke.

What happened to the original roff? I mean, groff is just a gnu 
replacement for roff. Maybe switch back to the original?

The sources to all of DWB are available from ATT:

http://www2.research.att.com/~astopen/download/

It needs a bit of work to get it to build on NetBSD though.

Robert Swindells

Re: Removing ARCNET stuffs

[Robert Swindells]

David Holland dholland-t...@netbsd.org wrote:
On Thu, May 28, 2015 at 08:06:56PM +0200, Tom Ivar Helbekkmo wrote:
  Me, too.  What NetBSD offers, that no other O/S offers, is the support
  for platforms that are no longer mainstream.  I've run it on Sparc and
  VAX processors for years, and hope to continue playing with these old
  machines.  I enjoy reading about others running NetBSD on even more
  exotic platforms.  (Incidentally, and I run OmniNet (an ancient 2Mbps
  token ring network) between machines in my home lab that are too old to
  even run NetBSD.)

I don't think (in general) that removing things is a good idea; but
it's increasingly difficult to keep NetBSD running on ancient
hardware. It's already infeasible to run the system compiler on most
such machines; this is only going to get worse with time. Other bloat
accumulates too, less rapidly perhaps but still so. The other day I
observed in chat that Someone(TM) needs to sit down with a slow
machine and a profiler for a while and find and kill all the
gratuitous bubble sorts, linear searches, and other things that run
too fast to be noticed on modern h/w; nobody disagreed, but on the
other hand nobody's been rushing to do it either. And other things
necessary for remaining relevant to semi-current hardware and usage,
like keeping up with X, desktop, and virtualization things, are often
in direct conflict with maintaining support for old hardware.

I tried booting -current on a mac68k earlier this week, it certainly
felt slower than I remembered.

[snip]

Because of these trends, I've been thinking for a while now that maybe
it's getting to be time to fork. That would allow having one project
that intends to stay current, with all the attendant requirements,
which probably mostly doesn't make sense on vintage hardware; and
another project that explicitly abandons most or all of that and
instead concentrates on being the best possible traditional multiuser
or workstation Unix, which does make sense on vintage hardware that
was designed for (or could be adapted to) those roles, and which also
makes sense on newer hardware to the extent it's consistent with the
traditional role.

I started using NetBSD because I wanted to use it on embedded
systems. Being able to use exactly the same OS on a desktop machine
for development was a big help and something that you don't really get
with Linux as there are so many different source trees.

Robert Swindells

Re: Removing ARCNET stuffs

[Robert Swindells]

Radoslaw Kujawa radoslaw.kuj...@c0ff33.net wrote:
 On 28 May 2015, at 10:30, Ryota Ozaki ozak...@netbsd.org wrote:
 
 On Thu, May 28, 2015 at 3:58 PM, Frank Wille fr...@phoenix.owl.de wrote:
 On Thu, 28 May 2015 11:57:11 +0900
 Ryota Ozaki ozak...@netbsd.org wrote:
 
 As far as I can see Arcnet is only used by the Amiga bah(4) driver.
 Isn't it possible to keep it somehow, as an MP-safe network stack would
 be irrelevant for the Amiga platform?
 
 We could keep it with some pain, but we cannot keep it working if there is
 really no user. (I'm not sure if it works or not even now.) Is it still
 worthwhile?
 
 I will not insist in keeping it when there is pain to do so. And you may
 be right that there is no user, but this is valid for a lot of platforms
 and drivers.
 
 
 Anyway I don't proceed this attempt ignoring your request.
 I wish there were actual users though...
 
 Maybe we can wait for a few days to give more potential users the chance
 to read these messages on the port-amiga list?
 
 Sure. I was a bit eager.
 
 
 In the meantime I will talk with other Amiga users if anybody owns such
 a board. Probably is@ still got one, as he was working on the driver many
 years ago.
 
 Thanks!
 
 
 When nothing happens and nobody is able to test it, we can remove the code.
 
 Okay, I'm waiting more.

There are companies still making PCI Express ARCnet interface cards,
hubs and converter devices:
http://www.ccontrols.com/arccontrol/nims.htm

I'm not entirely sure that removing support for a standard that is
still actually used out in the world is a good idea. Maybe it is not
used much with NetBSD, since we only have amiga-specific driver. One
more downside, is that anything ARCnet related is rather expensive now
(around $400 for a single new PCI interface card).

The same arguments might be made against the plan to remove ATM
support.

I wish I had more free time... fixing ARCnet and implementing support
for newer interface cards seems like an interesting project.

Support for several legacy protocols was removed in recent years. I
fear that our networking stack is becoming more and more IP and
Ethernet centric.

It isn't as bad as the Linux stack yet but I would also like to see a
variety of protocols in the tree. Even if they don't always work I
have found it useful to be able to look at other ways of doing stuff.

I have been doing a bit of work on cleaning up some old Chaosnet and
CAN code recently.

Robert Swindells

Re: Re HDMI transmitter interface

[Robert Swindells]

Manuel Bouyer wrote:
On Mon, Sep 22, 2014 at 07:15:00PM +0100, Robert Swindells wrote:
 
 Manuel Bouyer wrote:
 I made some progress on the TDA19988 HDMI transmitter driver as
 found in the beaglebone black (doens't work yet, sorry :).
 The driver will attach directly to the i2c bus, because other
 devices are also connected to this bus (eeprom, the power managenent IC, and
 more depending on connected capes). Then the TDA19988 driver and the
 video drivers have to talk together: the TDA19988 driver knows when a
 monitor is connected/disconnected and also can read the EDID, and
 the video driver knows which mode to select.
 
 Had you considered using the drmkms code for this SoC ?

No, I though drmkms was x86 only.

It can be used on any architecture.

 
 Current Linux sources have a driver for the display and for this HDMI
 transmitter.
 
 They were added to Linux after the last import that riastradh@ made so
 are not in the NetBSD tree yet.

What is the licence of this code ? I think it's a case where it would be
better to avoid the GPL.

I had not checked the licence when I wrote the original email, it is
GPL v2 and I agree that we wouldn't want it in tree.

Both bits were written by the same person (at TI), maybe ask if they
would dual licence it.

The drm code is licenced under mixture of BSD and GPL. The core stuff
and mass market GPU drivers are BSD, more recent SoC drivers look to
be mostly GPL.

We might want a plan for how to do framebuffers and X11 across all the
SoCs. Do we stick to using wsfb and xf86-video-wsfb or recommend that
new ports use drmkms and either xf86-video-modeswitching or a more
specific X11 driver ?

Maybe take this to tech-x11 ?

Robert Swindells