Re: CVS commit: src/sys/compat/netbsd32

2024-04-30 Thread Martin Husemann
On Tue, Apr 30, 2024 at 05:10:22PM +, Michael van Elst wrote: > Module Name: src > Committed By: mlelstv > Date: Tue Apr 30 17:10:22 UTC 2024 > > Modified Files: > src/sys/compat/netbsd32: netbsd32_sysent.c > > Log Message: > Enable compat sigreturn system call. Please check

Re: Forcing a USB device to "ugen"

2024-03-26 Thread Martin Husemann
On Tue, Mar 26, 2024 at 09:09:57AM +0100, Manuel Bouyer wrote: > On Tue, Mar 26, 2024 at 12:25:07AM +, Taylor R Campbell wrote: > > This is how it works in other systems like Linux with > > USBDEVFS_CLAIMINTERFACE, and that's the model that libusb is built > > around. It's a nontrivial change

Re: Fullfs file system

2024-03-20 Thread Martin Husemann
On Wed, Mar 20, 2024 at 10:17:23AM +, Ice Cream wrote: > Hi, when I try to run `mount_full /root/xyz/a /root/xyz/b` > I get the following error: > `mount_full: /root/xyz/a on /root/xyz/b: Operation > not supported by device` > Any tips for debugging this? Does your kernel have

Re: hardclock(9) could go.

2024-03-20 Thread Martin Husemann
On Wed, Mar 20, 2024 at 05:32:10AM +, Mathew, Cherry G.* wrote: > I look forward to your comments and test results, if any. I think moving heartbeat() to a callout context voids it's purpose. Martin

Re: Fullfs file system

2024-02-28 Thread Martin Husemann
On Wed, Feb 28, 2024 at 12:17:54PM +, Ice Cream wrote: > Hi, is anyone working on this > https://wiki.netbsd.org/projects/project/fullfs/ ? If not, I'd like to > take it up. Can anybody give detailed info about it and point to files > in the source code that need to be worked on? This is all

Re: Fixing, reestoring DEC FDDI (DEFPA/DEFEA/DEFTA/DEFQA) in 8.2, 9.2; restore to -current?

2024-02-11 Thread Martin Husemann
On Sun, Feb 11, 2024 at 09:29:22PM +, Jonathan Stone wrote: > I don;t want to re-create the hack of having two different initialisers for > the IEE 802 (sic) [*] portions of "struct ethercom'. > A cleaner solution is to declare a new struct with all the members of 'struct > ethercom', except

Re: PSA: Clock drift and pkgin

2023-12-30 Thread Martin Husemann
On Sat, Dec 30, 2023 at 06:25:29PM +, Jonathan Stone wrote: > You can only do tickless if you can track how much time is elapsing when no > ticks fire, or none are pending. > I don't see how to do that without a high-res timer like a CPU cycle counter, > or I/O bus cycle counter, > or

Re: Change max ttys from 8 to 12?

2023-12-19 Thread Martin Husemann
On Tue, Dec 19, 2023 at 11:10:52AM +0100, Dan-Simon Myrland wrote: > This might be bikeshedding, but would it make sense to change the > maximum allowed ttys, on commodity architectures like i386/amd64 at > least, to 12? I guess most people just don't use Ctrl-Alt-Fn a lot (but instead run X with

Re: PVH boot with qemu

2023-12-11 Thread Martin Husemann
On Mon, Dec 11, 2023 at 10:22:18AM +0100, Emile `iMil' Heitor wrote: > Or would you prefer the same kernel to be able to boot in both XENPVH and > GENPVH modes? I am focusing on making the resulting kernel smaller but this > could be done also. Can you use a separate entry point and optimize the

Re: [RFC 2] userconf(4): 2nd proposal

2023-11-04 Thread Martin Husemann
On Sat, Nov 04, 2023 at 11:25:01AM +0100, tlaro...@kergis.com wrote: > I think that my second proposal is the simplest, allowing not breaking > existing and introducing extensions without much typing. This whole thing still makes no sense to me. You can do what you want with userconf already and

Re: [RFC] userconf(4) modification

2023-11-03 Thread Martin Husemann
On Thu, Nov 02, 2023 at 05:32:20PM +0100, tlaro...@kergis.com wrote: > On Thu, Nov 02, 2023 at 05:05:53PM +0100, Martin Husemann wrote: [..] > > Something like: > > > > uc> drm off > > > > and then have the drm command use a fixed build-in table of driver nam

Re: [RFC] userconf(4) modification

2023-11-02 Thread Martin Husemann
I would prefer to have a special new command that does all the magic internaly, and don't waste code and complexity on pattern matching and generalizations. Something like: uc> drm off and then have the drm command use a fixed build-in table of driver names to disable individual drivers.

Re: boot.cfg location (was: GPT attributes in dkwedge [PATCH])

2023-09-25 Thread Martin Husemann
On Mon, Sep 25, 2023 at 10:43:56AM +0200, Edgar Fuß wrote: > > boot[].cfg is > searched in EFI par[tit]ion /EFI/NetBSD/boot.cfg > > and root partition /boot.cfg. > But how can EFI locate it on the root partition if it tells where the root > partition lives? Not EFI, but the bootloader. It

Re: GPT attributes in dkwedge [PATCH]

2023-09-25 Thread Martin Husemann
On Mon, Sep 25, 2023 at 05:57:49AM +, Emmanuel Dreyfus wrote: > Bootme tels bootstrap where to look root partition. bootme.cfg is > searched in EFI paririon /EFI/NetBSD/boot.cfg and root partition /boot.cfg. I would describe it differently: - firmware finds bootloader "somewhere" on some

Re: GPT attributes in dkwedge [PATCH]

2023-09-24 Thread Martin Husemann
On Sun, Sep 24, 2023 at 05:41:30PM +, Taylor R Campbell wrote: > The documentation in gpt(8) needs to be clarified -- and I'm not sure > there's any other canonical reference about it in any of our > documentation -- but it sounds to me like it is supposed to be: > > (a) where NetBSD's

Re: GPT attributes in dkwedge [PATCH]

2023-09-19 Thread Martin Husemann
On Mon, Sep 18, 2023 at 10:41:56PM -, Michael van Elst wrote: > So in many cases bootme marks the root partition. It is rarely > used on the EFI partition, but that's also a possibility. I guess it comes down to what bootselector your setup is for. IMO the ideal setup is for all possilble

Re: GPT attributes in dkwedge [PATCH]

2023-09-18 Thread Martin Husemann
On Mon, Sep 18, 2023 at 06:14:58PM +0100, David Brownlee wrote: > Specifically in the absence of any other information (empty devname? > etc), would it not be reasonable to fall back to the bootme marked > filesystem as a root filesystem candidate? I'm thinking about > minimally configured disks

Re: GPT attributes in dkwedge [PATCH]

2023-09-16 Thread Martin Husemann
On Sat, Sep 16, 2023 at 06:51:40AM -, Michael van Elst wrote: > You can already specify the root in boot.cfg. OK, the man page needs an update. > >It would also be cool if boot.cfg could specify the partition to load > >the kernel from via something similiar to NAME=. > > You can already

Re: GPT attributes in dkwedge [PATCH]

2023-09-16 Thread Martin Husemann
On Sat, Sep 16, 2023 at 05:01:00AM +, Emmanuel Dreyfus wrote: > The patch moves the GPT parser out of dkwedge so that it can > be used by other kernel componentx. You calll gpt_walk() with > a callback invoked for each GPT entry. dkwedge use it to do the > job it was doing before, and

Re: GPT attributes in dkwedge [PATCH]

2023-09-15 Thread Martin Husemann
On Fri, Sep 15, 2023 at 08:28:13PM +, os...@netbsd.org wrote: > So no, Emmanuel's changes arn't needed if you really know what you're doing > on an install with sysinst, but a novice just following the default is > currently going to really be a long way from a bootable system. (I'm not >

Re: GPT attributes in dkwedge [PATCH]

2023-09-15 Thread Martin Husemann
On Fri, Sep 15, 2023 at 04:01:15PM +, Emmanuel Dreyfus wrote: > A multiboot bootloader cannot, because all the information that is passed > is about partition numbers. There is no way of specifying a LBA offset, > hence the setup where you have a GPT inside raidframe seems impossible > to

Re: GPT attributes in dkwedge [PATCH]

2023-09-15 Thread Martin Husemann
On Fri, Sep 15, 2023 at 03:15:10PM +, Emmanuel Dreyfus wrote: > On Fri, Sep 15, 2023 at 03:06:46PM -, Michael van Elst wrote: > > What about just telling the kernel what to use in /boot.cfg ? > > No need to add more magic to the kernel. > > Ths user took care of setting bootme so that

Re: GPT attributes in dkwedgeq

2023-09-12 Thread Martin Husemann
On Tue, Sep 12, 2023 at 04:22:04PM +, Emmanuel Dreyfus wrote: > Right, it is bad design. Re-parsing the GPT in raidframe code seems wrong > too. Shall I modify struct dkwedge_info to add an union for the underlying > partition entry? That way, we can look for specific detail such as a >

Re: GPT attributes in dkwedgeq

2023-09-12 Thread Martin Husemann
On Tue, Sep 12, 2023 at 08:35:00AM +, Emmanuel Dreyfus wrote: > How are we supposed to discover the start block number? All rf_buildroothack() > knows is dk_nwedges from struct disk. It gets struct dkwedge_info using > dkwedge_find_by_parent(), which second argument seems to be the first dk

Re: GPT attributes in dkwedgeq

2023-09-12 Thread Martin Husemann
On Tue, Sep 12, 2023 at 07:29:57AM +, Emmanuel Dreyfus wrote: > On Tue, Sep 12, 2023 at 09:27:50AM +0200, Martin Husemann wrote: > > partnum here is what gpt(8) calls index? > > I was more thinking about wedge number: wedgenum would be a better name. I don't mind the na

Re: GPT attributes in dkwedgeq

2023-09-12 Thread Martin Husemann
On Tue, Sep 12, 2023 at 07:21:10AM +, Emmanuel Dreyfus wrote: > 2b) struct dkwedge_softc is private, we could add a field here > without being intrusive, it would just need accessor functions: > int dkwedge_set_flags(struct disk *pdk, int partnum, int flags); > int dkwedge_get_flags(struct

vfs_lockf changes (was: CVS commit: src)

2023-09-11 Thread Martin Husemann
On Sun, Sep 10, 2023 at 02:45:53PM +, Andrew Doran wrote: > Module Name: src > Committed By: ad > Date: Sun Sep 10 14:45:53 UTC 2023 > > Modified Files: > src/common/lib/libc/gen: radixtree.c > src/sys/kern: init_main.c kern_descrip.c kern_lwp.c kern_mutex_obj.c >

Re: Testing Emulation Syscalls

2023-08-02 Thread Martin Husemann
On Wed, Aug 02, 2023 at 05:17:45AM +1000, matthew green wrote: > have we considered checking in tiny binaries actually built for > the emulation and using them? I'm fine with that, as long as we have some setup to reproduce the binaries easily/reliably. Sometimes we discover bugs in the tests and

Re: Testing Emulation Syscalls

2023-08-01 Thread Martin Husemann
On Tue, Aug 01, 2023 at 12:43:50PM -0400, Theodore Preduta wrote: > My understanding of the "without Linux dev tools and libs around" part > is that each test case would be a separate (static Linux) binary that is > just a main() that only directly calls syscalls. Yes. > And then I guess

Re: Testing Emulation Syscalls

2023-08-01 Thread Martin Husemann
On Tue, Aug 01, 2023 at 11:48:21AM -0400, Theodore Preduta wrote: > I don't think so. If the binary starts under Linux emulation then the > kernel will expect that the syscall arguments follow Linux's calling > convention. (Which I guess could be done, but, correct me if I'm wrong, > are we not

Re: Testing Emulation Syscalls

2023-08-01 Thread Martin Husemann
On Tue, Aug 01, 2023 at 01:34:54PM +0300, Valery Ushakov wrote: > As for testing emulated syscalls - can we solve this problem with a > bit of elf branding to convince the kernel to start the binary under > emulation directly? Inventing a whole new backdoor API for that seems > kinda an overkill.

Re: Testing Emulation Syscalls

2023-08-01 Thread Martin Husemann
On Mon, Jul 31, 2023 at 05:03:48PM -0400, Theodore Preduta wrote: > One idea (mentioned in the original thread) would be to introduce a > syscall along the lines of > > int emul_syscall(const char *emul_name, int number, ...) > > which executes a single syscall. The flaw with this idea is

Re: DRM/KMS: vmwgfx driver is now available

2023-07-22 Thread Martin Husemann
On Sun, Jul 23, 2023 at 01:20:31AM +0900, PHO wrote: > That still means we have to allocate the real framebuffer in VRAM doesn't > it? Unfortunately we just can't do it in the case of vmwgfx. I'm not sure (not very fammiliar with this code) - there is a WSFB_VRAM_IS_RAM flag (used e.g. in

Re: DRM/KMS: vmwgfx driver is now available

2023-07-22 Thread Martin Husemann
On Sat, Jul 22, 2023 at 01:23:39PM +, Taylor R Campbell wrote: > Is there a way we could just use or add a simple hook in genfb or > rasops for when there's dirty areas to update, so we don't have to > copy & paste all of that cruft from genfb and drmfb? > > It looks like a painful

Re: [PATCH] Driver for Elantech I2C touchpad

2023-07-18 Thread Martin Husemann
On Sat, Jul 15, 2023 at 03:48:54AM +0200, Vladimir 'phcoder' Serbinenko wrote: > I've submitted a similar patch for OpenBSD recently and it got merged. It > adds support for Elantech I2C touchpad used on many laptops. Tested on my > Chromebook Elemi Do you know where the compat list comes from?

Re: [PATCH] style(5): No struct typedefs

2023-07-14 Thread Martin Husemann
On Fri, Jul 14, 2023 at 12:36:30PM +0200, Johnny Billquist wrote: > It also brings that if you want to change the definition, you change it in > one place, and not 1000. Only if you change the name of the struct or decide it is not going to be a struct any more. All that is to be duplicated (from

Re: [PATCH] style(5): No struct typedefs

2023-07-14 Thread Martin Husemann
On Fri, Jul 14, 2023 at 01:00:26AM +0200, Johnny Billquist wrote: > Using "typedef struct bus_dma_tag *" instead of "typedef void *" will do the > same thing. That is no reason at all why to skip the typedef. We want to avoid having to #include the header where that typedef lives. The typedef

Re: [PATCH] style(5): No struct typedefs

2023-07-11 Thread Martin Husemann
On Tue, Jul 11, 2023 at 10:17:24AM +, Taylor R Campbell wrote: > Objections? This is a very good change. Martin

Re: Anonymous vnodes?

2023-06-27 Thread Martin Husemann
On Tue, Jun 27, 2023 at 05:20:50PM +0200, Reinoud Zandijk wrote: > That's completely normal. If a file is created in a file system and its > unlinked its effectively in this state. While that is true, a vnode is an internal representation of some entity in some file system. What you really want

Re: RFC: Native epoll syscalls

2023-06-21 Thread Martin Husemann
On Wed, Jun 21, 2023 at 01:50:47PM -0400, Theodore Preduta wrote: > There are two main benefits to adding native epoll syscalls: > > 1. They can be used to help port Linux software to NetBSD. Well, syscall numbers are cheap and plenty... The real question is: is it a usefull and consistent API

Re: Compilation failures in current

2023-06-21 Thread Martin Husemann
On Wed, Jun 21, 2023 at 05:29:08AM +0200, bsd...@tuta.io wrote: > Since past 3?4 days, I am getting consistent failures while compiling the > kernel ? current. Did you update the whole source tree? How are you compiling your kernel? Martin

Re: How to submit patches?

2023-05-07 Thread Martin Husemann
On Sun, May 07, 2023 at 04:56:33PM +0200, tlaro...@polynum.com wrote: > I'm a bit reluctant to put all the platform lists in copy, since this > is typically generic: it deals with the monitor capacities, updating > the VESA DMT specs... I pointed a few people at your mail, but maybe you could

Re: How to submit patches?

2023-05-06 Thread Martin Husemann
On Sat, May 06, 2023 at 12:12:54PM +0200, tlaro...@polynum.com wrote: > Hello, > > On Mon, 27 Feb 2023 12:33:32 +0100, I sent to this list a collection of > patches for sys/dev/videomode/, starting by updating the DMT to the > latest, and planning to review further the code (sending patches >

Re: kernel goes dark on boot

2023-04-07 Thread Martin Husemann
On Fri, Apr 07, 2023 at 12:05:27PM +, Emmanuel Dreyfus wrote: > On Thu, Apr 06, 2023 at 05:08:34PM +0200, Martin Husemann wrote: > > I wonder if tuning EFI_ALLOCATE_MAX_ADDRESS in > > src/sys/arch/i386/stand/efiboot/Makefile.efiboot would be enough. > > No success. Here

Re: kernel goes dark on boot

2023-04-06 Thread Martin Husemann
On Thu, Apr 06, 2023 at 04:13:45PM +, Emmanuel Dreyfus wrote: > If I understand correctly, chaning EFI_ALLOCATE_MAX_ADDRESS > will change efi_loadaddr, which means it will only change > the source address for startprog64(), not the destination. I am not sure, but I thought the efi code would

Re: kernel goes dark on boot

2023-04-06 Thread Martin Husemann
I wonder if tuning EFI_ALLOCATE_MAX_ADDRESS in src/sys/arch/i386/stand/efiboot/Makefile.efiboot would be enough. Martin

Re: Emulating missing linux syscalls project

2023-03-29 Thread Martin Husemann
On Tue, Mar 28, 2023 at 03:32:35PM -0700, Zophiel wrote: > - What binary's in the current NetBSD stack does not run compact_test as a > test case increasing order of missing test cases ? The only regular compat_* tests running are compat_netbsd32, that is e.g. testing a NetBSD/i386 userland on a

Re: NetBSD 10.0 BETA kernel testing: framebuffer

2023-01-22 Thread Martin Husemann
On Sun, Jan 22, 2023 at 02:56:47PM +0100, tlaro...@polynum.com wrote: > no data for est. mode 640x480x67 [..] > I have not updated the book blocks. Is the 10.0 kernel expecting to have > hints about the modes from the bootloader i.e. a new install would > have updated the boot blocks and I would

Re: kernel goes dark on boot

2023-01-12 Thread Martin Husemann
On Thu, Jan 12, 2023 at 02:02:30PM +, Emmanuel Dreyfus wrote: > It goes dark when kernel starts displaying, before DRM takes over, > hence userconf is not usable. Can you play with different gop commands? This sounds like broken firmware to me. Martin

Re: SCSI Polled io fixes for mac68k with PDMA enabled.

2022-12-27 Thread Martin Husemann
On Tue, Dec 27, 2022 at 04:54:44PM +, David Brownlee wrote: > Might it be possible to detect this at runtime - potentially by > trapping a timeout and downgrading to polled io? Isn't this just a quirk for a specific target? Martin

Re: ci_want_resched bits vs. MD ci_data.cpu_softints bits

2022-12-03 Thread Martin Husemann
On Thu, Jul 07, 2022 at 09:22:42PM +0200, Martin Husemann wrote: > I guess in older times ci->ci_want_resched was used as a boolean flag, so only > 0 or !0 did matter - but nowadays it is a flag word of various bits: > > #define RESCHED_REMOTE 0x01/* request is f

Re: Can't mount root partition after rebuilding kernel with DKWEDGE_METHOD_MBR

2022-09-29 Thread Martin Husemann
On Thu, Sep 29, 2022 at 08:25:00PM +0700, Pham Ngoc-Dung wrote: > I tried dkctl. But it said "/dev/rwd0: addwedge: Device busy" every time. > However, I noticed that when I booted from the installation drive, the Linux > partitions appeared. Try "dkctl wd0 listwedges" and see if they are already

Re: Can't mount root partition after rebuilding kernel with DKWEDGE_METHOD_MBR

2022-09-28 Thread Martin Husemann
On Wed, Sep 28, 2022 at 04:52:43PM +, Pham Ngoc-Dung wrote: > Hi. On my hard drive (wd0, MBR), I have 3 partitions originally for Linux, > including a boot partition (ext2 formatted), and another partition with > NetBSD installed. > For a reason I wanted to mount the Linux boot partition,

Re: Open master pty (/dev/ptmx) non blocking

2022-09-23 Thread Martin Husemann
On Fri, Sep 23, 2022 at 01:26:00PM +0200, Anthony Mallet wrote: > On Friday 23 Sep 2022, at 10:29, RVP wrote: > > So, O_NONBLOCK is, at least, _definitely_ non-portable. Best to use > > fcntl() here and not depend on a Linux-specific behaviour. > > Fair enough :) > > Then, shouldn't the open(2)

Re: Module autounload proposal: opt-in, not opt-out

2022-08-08 Thread Martin Husemann
On Mon, Aug 08, 2022 at 09:24:28AM -0400, Greg Troxel wrote: > Given where we are, do you really mean > > we should withdraw every module from autoload that does not have a > documented test result, right now? > > It seems far better to have them stay loaded than be unavailable. I'm not

Re: Module autounload proposal: opt-in, not opt-out

2022-08-08 Thread Martin Husemann
On Sun, Aug 07, 2022 at 11:08:47PM +, Taylor R Campbell wrote: > Some modules might still be unsafe to unload, which is a bug -- but at > least this way accidentally creating the wrong network interface or > opening the wrong device won't set a ten-second time-bomb for the > system like I

Re: bus_space_barrier semantics

2022-07-16 Thread Martin Husemann
On Sat, Jul 16, 2022 at 01:42:38PM -0700, Jason Thorpe wrote: > Didn't OpenBSD remove the offset / length arguments? Anyway, I'm not > particularly concerned about this part, but it would be a nice wart to > rid ourselves of. Since these calls (now) should be relatively rare, and conversion

ci_want_resched bits vs. MD ci_data.cpu_softints bits

2022-07-07 Thread Martin Husemann
Hey folks, while staring at PR 55415 and recently having learned that powerpc fast softints are broken, I found a strange ancient line of code that I think is not correct in the current world order any more: Index: kern_synch.c ===

Re: Scanning floppy devices with assumed density

2022-07-03 Thread Martin Husemann
On Sun, Jul 03, 2022 at 05:21:27AM -, Michael van Elst wrote: > Another question of course is why the isa fd driver reads a disklabel at all > when it (ab-)uses the partition number to select densities. Yeah, can we commit that fix with a log like: fd(4): only support GPT partitioning on

Re: mfii hanging on boot

2022-06-27 Thread Martin Husemann
On Tue, Jun 28, 2022 at 01:05:46AM +0900, Masanobu SAITOH wrote: > It's just to make the same line as of bus_space_write_8(). > I don't know why it's "&& 0"ed. I have no clue about the hardware, so can only guess: > --- > static void > mfii_start(struct mfii_softc *sc, struct mfii_ccb

Re: kern/subr_devsw.c build error

2022-06-05 Thread Martin Husemann
On Sun, Jun 05, 2022 at 04:43:38AM +, James Browning wrote: > Hello, > > I am attempting to compile the kernel and getting blocked by the following > error: > >../../../../kern/subr_devsw.c:424:29: error: 'bi' may be used > uninitialized in this function [-Werror=maybe-uninitialized] >

Re: Tentative Proposal for Gsoc : Emulating missing linux syscalls (350h)

2022-03-11 Thread Martin Husemann
On Sat, Mar 12, 2022 at 12:01:25AM +0200, Ahmed bahloul wrote: > Hello, > I have made my Tentative Proposal for : Emulating missing linux syscalls > project. Hello Ahmed, great that you are interested in this project and enhancing NetBSD! After reading your proposal it seems to me you may have

Re: membar_enter semantics

2022-02-11 Thread Martin Husemann
On Fri, Feb 11, 2022 at 11:33:39AM -0500, Mouse wrote: > >> sparc64: [...] > > Almost forgot to mention ... I wouldn't read too much into how sparc64's > > bar$ > > Is that choice run-time configurable? I thought it was baked into the > hardware...but admittedly that's based on documents I read

Re: Some guidance/suggestion please

2022-01-14 Thread Martin Husemann
On Fri, Jan 14, 2022 at 09:11:08AM -0800, Paul Goyette wrote: > #ifdef ALTQ > altq-code-part-A > #endif > (common code) > #ifdef ALTQ > altq-code-part-B > #endif > ... > > The existing module_hook mechanism doesn't help us

Re: procfs files vs symlink

2022-01-11 Thread Martin Husemann
On Tue, Jan 11, 2022 at 11:10:24AM +0100, Manuel Bouyer wrote: > +static inline bool > +procfs_proc_is_linux_compat(void) > +{ > + const char *emulname = curlwp->l_proc->p_emul->e_name; > + return (strncmp(emulname, "linux", 5) == 0); > +} Not a big deal, but wouldn't it be better to give

Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl

2021-10-29 Thread Martin Husemann
On Thu, Oct 28, 2021 at 11:14:39AM -0700, Jason Thorpe wrote: > We really just need to kill the sigcontext stuff completely. More to the > point, we should version sigaction() before (or concurrently with) adding > whatever call we add here so as to ensure that it will only ever be a >

Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl

2021-10-16 Thread Martin Husemann
On Sat, Oct 16, 2021 at 08:11:47AM -0500, John Marino (NetBSD) wrote: > Alright, so I think we have established that it's impossible to > provide KERN_PROC_SIGTRAMP as it functions on FreeBSD and DragonFly. > The purpose of that sysctl is to get the address range of the single > signal trampoline.

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

2021-09-23 Thread Martin Husemann
On Thu, Sep 23, 2021 at 05:10:46PM +, co...@sdf.org wrote: > Hi David, > > On Thu, Sep 23, 2021 at 05:41:45PM +0100, David Brownlee wrote: > > If gpu firmware is somewhat special, is there any sense in moving it > > to /usr/libdata/firmware/gpu/... ? > > It's not particularly special, but

Re: Some changes to autoconfiguration APIs

2021-08-01 Thread Martin Husemann
On Sun, Aug 01, 2021 at 07:57:20AM -0700, Jason Thorpe wrote: > The situation hasn't changed. I'm still waiting for concrete proposals. The concrete proposal is backout - if there is no better idea how to deal with it properly. Martin

Re: Some changes to autoconfiguration APIs

2021-08-01 Thread Martin Husemann
On Mon, May 10, 2021 at 10:30:09PM -0700, Jason Thorpe wrote: > > > On May 10, 2021, at 7:58 PM, matthew green wrote: > > > > please, can we revert and re-do with a type-safe API. > > I don't plan to revert, but I will consider a betterly-typed API > that's not extremely cumbersome to use. I

Re: MUTEX_CAS() and memory barriers

2021-07-25 Thread Martin Husemann
On Sat, Jul 24, 2021 at 05:59:59PM -0700, Jason Thorpe wrote: > Anyway, I?m much more concerned with (1). I think at the very least, alpha > and sparc64 don?t need to define their own _lock_cas() and can just use > atomic_cas_ulong()? furthermore, I think we can just let that be the default >

Re: getconf(1) / sysconf(3) - add additional variables?

2021-07-02 Thread Martin Husemann
On Fri, Jul 02, 2021 at 03:39:19PM +0100, Michael-John Turner wrote: > Indeed, I mean sysconf(3). Sorry for the confusion, I started typing my > email, did some further investigation and then didn't edit it correctly. Still doesn't make sense to me - it is a compile time constant, I see no way to

Re: getconf(1) / sysconf(3) - add additional variables?

2021-07-02 Thread Martin Husemann
On Fri, Jul 02, 2021 at 02:21:39PM +0100, Michael-John Turner wrote: > Hi, > > While attempting to package Starship for pkgsrc, I noticed that getconf(1) > is missing several variables that are available on both OpenBSD and > FreeBSD (I'm assuming because they're not returned by sysconf(3)). For

Re: protect pmf from network drivers that don't provide if_stop

2021-06-29 Thread Martin Husemann
On Wed, Jun 30, 2021 at 10:20:08AM +0930, Brett Lymn wrote: > So, does this mean its ok to commit what I proposed to prevent the panic > with a view to the drivers being fixed in the future? Yes, probably good to do that for know (and please file a PR and assign to me so I don't forget to add a

Re: protect pmf from network drivers that don't provide if_stop

2021-06-29 Thread Martin Husemann
On Tue, Jun 29, 2021 at 09:57:27PM +0930, Brett Lymn wrote: > Is that going to be soon? I was thinking of doing a sweep of the usb network > drivers to fix > this. It is not affecting me at the moment because the driver for wireless I > am using at > the moment actually defines if_stop. It is

Re: protect pmf from network drivers that don't provide if_stop

2021-06-29 Thread Martin Husemann
On Tue, Jun 29, 2021 at 03:46:20PM +0930, Brett Lymn wrote: > I turned up a fix I had put into my source tree a while back, I think at > the time the wireless driver (urtwn IIRC) did not set an entry for > if_stop. This is a driver bug, we should not work around it but catch it early and fix it.

Re: Introduction to posix_spawn/chdir

2021-06-27 Thread Martin Husemann
On Sat, Jun 26, 2021 at 03:02:35PM -0700, Chris Hanson wrote: > That's great, I'm more curious about the implementation plan. I would understand this question if we were talking about implementing posix_spawn from scratch, but we have that since 6.0 and the "plan" is to enhance the exisiting

Re: Introduction to posix_spawn/chdir

2021-06-25 Thread Martin Husemann
On Fri, Jun 25, 2021 at 02:45:59PM -0700, Chris Hanson wrote: > Also, exactly what form will posix_spawn chdir support take in your project? I'm not sure I understand the question correctly. There is an upcoming change for the next version of Posix in the Austin Group's bug tracker and the

Re: Kernel 9.1 panic with azalia

2021-06-25 Thread Martin Husemann
Also any reason to use 9.1 instead of 9.2 or 9.2_STABLE? (Not that I think it would make a difference for azalia) Martin

Re: Is there a command to change btime (creation time of files)?

2021-05-29 Thread Martin Husemann
On Sat, May 29, 2021 at 02:03:42PM -, Christos Zoulas wrote: > The baroque procedure is described in the manual page of utimes(2) where > one would expect it :-) We should also add a command for it to fsdb(8). Martin

Re: 9.1: boot-time delay?

2021-05-18 Thread Martin Husemann
On Tue, May 18, 2021 at 03:01:55PM -0400, Mouse wrote: > [ 3.288539] uhub2: 4 ports with 4 removable, self powered > [ 3.288539] uhub3: 6 ports with 6 removable, self powered > [25.272567] wd0 at atabus0 drive 0 > [25.273568] wd0: There are multiple things with long timeouts

Re: umodeswitch

2021-04-09 Thread Martin Husemann
On Fri, Apr 09, 2021 at 06:07:17PM +0200, Emmanuel Dreyfus wrote: > And as usual, they attach as umass devices instead of u3g. I added the > ids of the two devices in umodeswitch.c and now: > > umodeswitch0 at uhub1 port 3: Switching off umass mode > umodeswitch1 at uhub1 port 10: Switching off

Re: regarding the changes to kernel entropy gathering

2021-04-07 Thread Martin Husemann
On Wed, Apr 07, 2021 at 12:14:58PM -0700, Greg A. Woods wrote: > > You run it once. Manually. And never again. > > Nope, sorry, that's not a good enough answer. It is for the typical and default installs. > It doesn't solve the > problem of dealing with a lack of mutable storage. When you

Re: regarding the changes to kernel entropy gathering

2021-04-07 Thread Martin Husemann
On Wed, Apr 07, 2021 at 07:53:07AM -0400, matthew sporleder wrote: > So on a brand new installation/first boot why isn't the clock a > sufficiently random thing? (anymore?) Becaus it isn't random? > Hung and unusable systems are a big problem. Happening on the first > boot is not a good first

Re: regarding the changes to kernel entropy gathering

2021-04-07 Thread Martin Husemann
On Wed, Apr 07, 2021 at 07:05:12AM -0400, matthew sporleder wrote: > Is the issue gaw saw exclusive to xen first boots? Are there other > ways to end up in his situation? It happens on all new installations for machines with no RNG, which is the far majority of everything but "newish" amd64 and

Re: regarding the changes to kernel entropy gathering

2021-04-07 Thread Martin Husemann
On Tue, Apr 06, 2021 at 06:24:38PM +, Koning, Paul wrote: > > Isn't it as simple as: > > > > dd bs=32 if=/dev/urandom of=/dev/random > > > > ? > > That runs the risk of people thinking it adds entropy. I'd be more > comfortable with this: > > dd bs=32 if=/dev/zero

Re: regarding the changes to kernel entropy gathering

2021-04-07 Thread Martin Husemann
On Tue, Apr 06, 2021 at 03:12:45PM -0700, Greg A. Woods wrote: > > Isn't it as simple as: > > > > dd bs=32 if=/dev/urandom of=/dev/random > > No, that still leaves the question of _when_ to run it. (And, at least > at the moment, where to put it. /etc/rc.local?) Of course not! You run it

Re: regarding the changes to kernel entropy gathering

2021-04-06 Thread Martin Husemann
On Tue, Apr 06, 2021 at 10:54:51AM -0700, Greg A. Woods wrote: > Except it seems to be useless in practice without an initial seed, Yes. > And the stock implementation has no possibility of ever providing an > initial seed at all on its own (unlike previous implementations, and of > course

Re: Proposal draft [GSOC]

2021-04-06 Thread Martin Husemann
On Thu, Apr 01, 2021 at 11:47:22PM +0530, Piyush Sachdeva wrote: > To whomever it may concern, > Please find attached the proposal for the project of extending the standard > posix_spawn(3) to support chdir(2) in NetBSD. This is just a draft and I > would like to hear from you, about all the

Re: regarding the changes to kernel entropy gathering

2021-04-04 Thread Martin Husemann
On Sun, Apr 04, 2021 at 11:14:31AM -0700, John Nemeth wrote: > I understand the need for good random sources, and won't argue > it. My question is, how can we tell what random sources a system > actually has, i.e. is there some flag that cpuctl identify shows > when a system has

Re: nothing contributing entropy in Xen domUs? (causing python3.7 rebuild to get stuck in kernel in "entropy" during an "import" statement)

2021-03-30 Thread Martin Husemann
On Wed, Mar 31, 2021 at 12:12:31AM +, Taylor R Campbell wrote: > This is false. If the VM host provided a viornd(4) device then NetBSD > would automatically collect, and count, entropy from the host, with no > manual intervention. I would love to see instructions how to do this - I have not

Re: [NEWBIE] [GSOC]

2021-03-17 Thread Martin Husemann
On Wed, Mar 17, 2021 at 01:20:17PM +0530, Piyush Sachdeva wrote: > However I wanted to know how much of the project will be in user-land > and how much of it will be in the kernel space. As I have a 2018 > MacBook, I don?t have the luxury of dual booting it. Nearly all work will be in the

Re: Can WM_EVENT_COUNTERS be enabled default?

2021-01-27 Thread Martin Husemann
On Wed, Jan 27, 2021 at 03:44:29PM +0900, Kengo NAKAHARA wrote: > Sorry, I think LP64 system which does not have atomic_64 operations. Unrelated to this discussion: are there any such systems (that NetBSD supports)? I am not aware of any, so would be curious to learn about them. Martin

Re: CVS commit: src/sys/dev

2021-01-15 Thread Martin Husemann
On Sat, Dec 26, 2020 at 02:50:50PM +, Nia Alarie wrote: > Module Name: src > Committed By: nia > Date: Sat Dec 26 14:50:50 UTC 2020 > > Modified Files: > src/sys/dev: fss.c > > Log Message: > Check the return value of device_lookup_private against NULL. > > Reported-by:

Re: cmake hangs on kqueue

2021-01-12 Thread Martin Husemann
On Tue, Jan 12, 2021 at 01:11:00PM +0100, Manuel Bouyer wrote: > I think I've seen some mails about a similar problem in the past few months > but I don't remember the details (and couldn't find a PR about it either). That was supposed to be fixed by ticket #907, which got pulled up on May 13

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

2020-11-13 Thread Martin Husemann
On Fri, Nov 13, 2020 at 11:06:56PM +0100, Jaromír Dole?ek wrote: > There is no more automatic mode downgrade from DMA to PIO any more, so > if the controller misadvertises DMA support, but it actually doesn't > work, then I/O will just fail. This should be easy to test by adding flags to the wd

Re: kernel 8.2 and 9.1 crashes

2020-11-12 Thread Martin Husemann
On Fri, Nov 13, 2020 at 07:35:24AM +0100, tlaro...@polynum.com wrote: > I tried to recompile a kernel, with 8.2 and with 9.1 and both > crash, 9.1 with: > > unable to execute instruction 0x18 (SMEP) > > (from memory) This is (I guess) the kernel jumping through a NULL function pointer. > The

Re: Temporary memory allocation from interrupt context

2020-11-12 Thread Martin Husemann
On Thu, Nov 12, 2020 at 10:51:58AM +0100, Lars Reichardt wrote: > I was/am under the impression that the longtime goal is to move all > allocations out of interrupt paths and that kmem_intr_alloc is there > only for transition, I have doubts this will happen. That was my impression as well, so I

Re: Temporary memory allocation from interrupt context

2020-11-11 Thread Martin Husemann
On Wed, Nov 11, 2020 at 03:08:12PM +0100, Joerg Sonnenberger wrote: > On Wed, Nov 11, 2020 at 10:44:45AM +0100, Martin Husemann wrote: > > Consider the following pseudo-code running in softint context: > > Why do those items not have a link element inside, so that no addi

Re: Temporary memory allocation from interrupt context

2020-11-11 Thread Martin Husemann
On Wed, Nov 11, 2020 at 08:26:45AM -0500, Greg Troxel wrote: > > LOCK(st); > > size_t n, max_n = st->num_items; > > some_state_item **tmp_list = > > kmem_intr_alloc(max_n * sizeof(*tmp_list)); > > kmem_intr_alloc takes a flag, and it seems that you need to pass > KM_NOSLEEP,

  1   2   3   4   5   6   7   >