Re: Forcing a USB device to "ugen"

Jason Thorpe writes: > 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". Is that fundamental, in that ugen has ioctls that are ugen-ish that uftdi does not? I am guessing you thought about fixing

Re: Polymorphic devices

Brad Spencer writes: > I don't know just yet, but there might be unwanted device reset the "use > the one you open" technique. That is, you might have to reset the chip > to change mode and if you support say, I2C and GPIO at the same time > (which is possible), but then change to just GPIO the

Re: Polymorphic devices

Brad Spencer writes: > The first is enhancements to ufdti to support the MPSSE engine that some > of the FTDI chip variants have. This engine allows the chip to be a I2C > bus, SPI bus and provides some simple GPIO, and a bunch of other stuff, > as well as the normal USB UART. It is not

Re: Maxphys on -current?

Brian Buhrow writes: > hello. I know that this has ben a very long term project, but I'm > wondering about the > status of this effort? I note that FreeBSD-13 has a Maxphys value of 1048576 > bytes. > Have we found other ways to get more throughput from ATA disks that obviate > the

Re: RFC: Native epoll syscalls

Mouse writes: >> It is definitely a real problem that people write linuxy code that >> seems unaware of POSIX and portability. > > While I feel a bit uncomfortable appearing to defend the practice (and, > to be sure, it definitely can be a problem) - but, it's also one of the > ways advancements

Re: RFC: Native epoll syscalls

Martin Husemann writes: > 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

Re: malloc(9) vs kmem(9) interfaces

Taylor R Campbell writes: > Right, so the question is -- can we get the attribution _without_ > that? Surely attribution itself is just a matter of some per-CPU > counters. Reading along, it strikes me there is a huge point implicit in your last sentence. I first thought of attribution as

Re: LINEAR24 userland format in audio(4) - do we really want it?

nia writes: > Unfortunately file formats are standardized but the > the way the audio APIs are implemented varies. :/ > >> It's now no longer broken to handle 24bit WAV files. > > This is true, but audioplay is hardly the only > consumer of the API and could easily be made to communicate > with

Re: USB-related panic in 8.2_STABLE

Timo Buhrmester writes: > Apparently out of nothing, one of our servers paniced. > > > uname -a gives: > > | NetBSD trave.math.uni-bonn.de 8.2_STABLE NetBSD 8.2_STABLE > | (MI-Server) #17: Fri Jul 16 14:01:03 CEST 2021 > |

Re: crash in timerfd building pandoc / ghc94 related

PHO writes: > On 2/6/23 5:27 PM, Nikita Ronja Gillmann wrote: >> I encountered this on some version of 10.99.2 and last night again on >> 10.99.2 from Friday morning. >> This is an obvious blocker for me for making 9.4.4 the default. >> I propose to either revert to the last version or make the

Re: Enable to send packets on if_loop via bpf

Ryota Ozaki writes: > In the specification DLT_NULL assumes a protocol family in the host > byte order followed by a payload. Interfaces of DLT_NULL uses > bpf_mtap_af to pass a mbuf prepending a protocol family. All interfaces > follow the spec and work well. > > OTOH, bpf_write to

Re: Enable to send packets on if_loop via bpf

Ryota Ozaki writes: > NetBSD can't do this because a loopback interface > registers itself to bpf as DLT_NULL and bpf treats > packets being sent over the interface as AF_UNSPEC. > Packets of AF_UNSPEC are just dropped by loopback > interfaces. > > FreeBSD and OpenBSD enable to do that by

Re: #pragma once

My quick reaction is that we should stick to actual standards, absent a really compelling case. This isn't compelling to me, and the point that linting for wrong usage isn't hard is a good one. I happen to be in the middle of a paper (from the guix crowd) about de-boostrapping ocaml. It's

Re: Can version bump up to 9.99.100?

David Holland writes: > On Fri, Sep 16, 2022 at 07:00:23PM +0700, Robert Elz wrote: > > That is, except for in pkgsrc, which is why I still > > have a (very mild) concern about that one - it actually compares the > > version numbers using its (until it gets changed) "Dewey" comparison > >

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

Paul Goyette writes: > (personal note) > It really seems to me that the current module sub-systems is at > best a second-class capability. I often get the feeling that > others don't really care about modules, until it's the only way > to provide something else (dtrace). This proposal feels

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

Martin Husemann writes: > I think that all modules that we deliver and declare safe for *autoload* > should require to be actually tested, and a basic test (for me) includes > testing auto-unload. That does not cover races that slip through "casual" > testing, but should have caught the worst

Re: New iwn firmware & upgrade procedure

Havard Eidnes writes: >> A quick skim of /libdata/firmware makes me think it is mostly not >> versioned. > > Really? I suspect all the if_iwn files are versioned; if it > follows the pattern for iwlwifi-6000g2a-5, the number behind the > last hyphen is the version number. Look at all the

Re: New iwn firmware & upgrade procedure

Havard Eidnes writes: > 1) Could the if_iwn driver fall back to using the 6000g2a-5 microcode >without any code changes? (My gut feeling says "yes", but I have >no existence proof of that.) Unless it's really necessary (ABI change in accessing device with new firmware), it seems that

Re: Slightly off topic, question about git

David Brownlee writes: > I suspect most of this also works with s/git/hg/ assuming NetBSD > switches to a mercurial repo Indeed, all of this is not really about git. Systems in the class of "distributed VCS" have two important properties: commits are atomic across the repo, not per file

Re: wsvt25 backspace key should match terminfo definition

RVP writes: > On Tue, 23 Nov 2021, Michael van Elst wrote: > >> If you restrict yourself to PC hardware (i386/amd64 arch) then >> you probably have either >> >> a PS/2 keyboard -> the backspace key generates a DEL. >> a USB keyboard -> the backspace key generates a BS. >> >> That's something

Re: wsvt25 backspace key should match terminfo definition

Valery Ushakov writes: > vt52 is different. I never used a real vt52 or a clone, but the > manual at vt100.net gives the following picture: > > https://vt100.net/docs/vt52-mm/figure3-1.html > > and the description > > https://vt100.net/docs/vt52-mm/chapter3.html#S3.1.2.3 > > Key

Re: wsvt25 backspace key should match terminfo definition

Johnny Billquist writes: >> For vt320 (where it *is* configurable) terminfo has >> >>$ infocmp -1 vt320 | grep kbs >>kbs=^?, > > Which I think it should be. But what does kbs mean? - the ASCII character sent by the computer to move the cursor left? - the ASCII character

Re: wsvt25 backspace key should match terminfo definition

Valery Ushakov writes: > On Tue, Nov 23, 2021 at 00:01:40 +, RVP wrote: > >> On Tue, 23 Nov 2021, Johnny Billquist wrote: >> >> > If something pretends to be a VT220, then the key that deletes >> > characters to the left should send DEL, not BS... >> > Just saying... >> >> That's fine

Re: timecounters

I think it makes sense to document them, and arguably each counter should have a man page, except for things that are somehow in timecounter(9) instead (if they don't have a device name?). signature.asc Description: PGP signature

Re: Representing a rotary encoder input device

What do other systems do? It strikes me what wsmouse feels like it is for things connected with the kbd/mouse/display world. To be cantankerous, using it seems a little bit like representing a GPIO input as a 1-button mouse that doesn't move. I would imagine that a rotary encoder is more

Re: SCSI scanners

Julian Coleman writes: > Can we get rid of the SCSI scanner support as well? It only supports old > HP and Mustek scanners, and its functionality is superseded by SANE (which > sends the relevant SCSI commands from userland). If it's really the case that SANE works with these, then that seems

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

Martin Husemann writes: > 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

Re: regarding the changes to kernel entropy gathering

Thanks - that is useful information. I think the big point is that the new seed file is generated from urandom, not from the internal state, so the new seed doesn't leaak internal state. The "save entropy" language didn't allow me to conclude that. Also, your explanation is about updating, but

Re: regarding the changes to kernel entropy gathering

Thor Lancelot Simon writes: > shuts down, again all entropy samples that have been added (which, again, > are accumulating in the per-cpu pools) are propagated to the global pool; > all the stream RNGs rekey themselves again; then the seed is extracted. It seems obvious to me that "extracting"

Re: ZFS: time to drop Big Scary Warning

chris...@astron.com (Christos Zoulas) writes: > That's a good test, but how does zfs compare in for the same test with lets > say ffs or ext2fs (filesystems that offer persistence)? With the same system, booted in the same way, but with 3 different filesystems mounted on /tmp, I get similar

Re: ZFS: time to drop Big Scary Warning

I got a suggestion to run atf with a ZFS tmp. This is all with current from around March 1, and is straight current, no Xen. Creating tank0/tmp and having it be mounted on /tmp failed the mount (but created the volume) with some sort of "busy" error. I already had a tmpfs mounted. Rebooting,

Re: ZFS: time to drop Big Scary Warning

"J. Hannken-Illjes" writes: >> On 19. Mar 2021, at 21:18, Michael wrote: >> >> On Fri, 19 Mar 2021 15:57:18 -0400 >> Greg Troxel wrote: >> >>> Even in current, zfs has a Big Scary Warning. Lots of people are using >>> it and i

ZFS: time to drop Big Scary Warning

Even in current, zfs has a Big Scary Warning. Lots of people are using it and it seems quite solid, especially by -current standards. So it feels times to drop the warning. I am not proposing dropping the warning in 9. Objections/comments? signature.asc Description: PGP signature

Re: kmem pool for half pagesize is very wasteful

Chuck Silvers writes: > in the longer term, I think it would be good to use even larger pool pages > for large pool objects on systems that have relatively large amount of memory. > even with your patch, a 1k pool object on a system with a 4k VM page size > still has 33% overhead for the

Re: fsync error reporting

Greg Troxel writes: > 1) operating system has a succcessful return from a write transaction to > a disk controller (perhaps via a controller that has a write-back > cache) > > 2) operating system has been told by the controller that the write has > actually completed

Re: fsync error reporting

David Holland writes: > > > everything that process wrote is on disk, > > > > That is probably unattainable, since I've seen it plausibly asserted > > that some disks lie, reporting that writes are on the media when this > > is not actually true. > > Indeed. What I meant to say is that

Re: fsync_range and O_RDONLY

David Holland writes: > Well, if you have it open for write and I have it open for read, and I > fsync it, it'll sync your changes. I guess maybe POSIX is wrong then :-) But as a random user I can type sync to the shell. > And report any errors to me, so if you're a database and I'm feeling

Re: fsync_range and O_RDONLY

David Holland writes: > Last year, fdatasync() was changed to allow syncing files opened > read-only, because that ceased to be prohibited by POSIX and something > apparently depended on it. I have a dim memory of this and mongodb. > However, fsync_range() was not also so changed. Should it

Re: partial failures in write(2) (and read(2))

David Holland writes: > Basically, it is not feasible to check for and report all possible > errors ahead of time, nor in general is it possible or even desirable > to unwind portions of a write that have already been completed, which > means that if a failure occurs partway through a write

Re: Temporary memory allocation from interrupt context

Martin Husemann writes: > 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)); >>

Re: Temporary memory allocation from interrupt context

Martin Husemann writes: > Consider the following pseudo-code running in softint context: > > void > softint_func(some_state *st, ) > { > LOCK(st); > size_t n, max_n = st->num_items; > some_state_item **tmp_list = > kmem_intr_alloc(max_n * sizeof(*tmp_list));

Re: New header for GPIO-like definitions

Julian Coleman writes: > name="LED activity" > name="LED disk5_fault" > > name="INDICATOR key_diag" > name="INDICATOR disk5_present" > > and similar, then parse that in MI code. Another approach would be to extend the fdt schema in the way they would if solving this problem and use

Re: New header for GPIO-like definitions

Julian Coleman writes: >> > #define GPIO_PIN_LED0x01 >> > #define GPIO_PIN_SENSOR 0x02 >> > >> > Does this seem reasonable, or is there a better way to do this? > >> I don't really understand how this is different from in/out. >> Presumably this is coming from some request from

Re: New header for GPIO-like definitions

Julian Coleman writes: > I'm adding a driver and hardware-specific properties for GPIO's (which pins > control LED's, which control sensors, etc). I need to be able to pass the > pin information from the arch-specific configuration to the MI driver. I'd > like to add a new

Re: make COMPAT_LINUX match SYSV binaries

co...@sdf.org writes: > I feel compelled to explain further: > any OS that doesn't rely on this tag is prone to spitting out binaries > with the wrong tag. For example, Go spits out Solaris binaries with SYSV > as well. > > Our current solution to it is the kernel reading through the binary, >

Re: make COMPAT_LINUX match SYSV binaries

co...@sdf.org writes: > As a background, some Linux binaries don't claim to be targeting the > Linux OS, but instead are "SYSV". > > We have used some heuristics to still identify those binaries as being > Linux binaries, like looking into the symbols defined by the binary. > > it looks like we

Re: autoloading compat43 on tty ioctls

chris...@astron.com (Christos Zoulas) writes: > Aside for the TIOCGSID bug which I am about to fix (it is in tty_43.c > and is used in libc tcgetsid(), all the compat tty ioctls are defined > in /usr/src/sys/sys/ioctl_compat.h... We can empty that file and try > to build the tree :-), but I am

Re: Sample boot.cfg for upgraded systems (rndseed & friends)

David Brownlee writes: > What would people think of installing an original copy of the etc set > in /usr/share/examples/etc or similar - its 4.9M extracted and ~500K > compressed and the ability to compare what is on the system to what it > was shipped with would have saved me so much effort

Re: Logging a kernel message when blocking on entropy

Andreas Gustafsson writes: > The following patch will cause a kernel message to be logged when a > process blocks on /dev/random or some other randomness API. It may > help some users befuddled by pkgsrc builds blocking on /dev/random, > and I'm finding it useful when testing changes aimed at

Re: Proposal to enable WAPBL by default for 10.0

Taylor R Campbell writes: [lots of good points, no disagreement] If /etc/master.passwd is ending up with junk, that's a clue that code that updates it isn't doing the write secondary file, fysnc it, rename, approach. As I understand it with POSIX filesystems you have to do that because there

Re: AES leaks, cgd ciphers, and vector units in the kernel

a data point on a machine from 2014: $ ./aestest -l BearSSL aes_ct Intel SSE2 bitsliced $ progress -f /dev/zero sh -c 'exec ./aestest -e -b 256 -c aes-xts -i "Intel SSE2 bitsliced" > /dev/null' 399 MiB 56.98 MiB/s ^C $ progress -f /dev/zero sh -c 'exec ./aestest -e -b 256 -c aes-xts -i

Re: AES leaks, cgd ciphers, and vector units in the kernel

Taylor R Campbell writes: >> What I meant is: consider an external USB disk of say 4T, which has a >> cgd partition within which is ffs. >> >> Someone attaches it to several systems in turn, doing cgd_attach, mount, >> and then runs bup with /mnt/bup as the target, getting deduplication >>

Re: AES leaks, cgd ciphers, and vector units in the kernel

Taylor R Campbell writes: >> I don't really see the new cipher as a reasonable option for removable >> disks that need to be accessed by older systems. I can see it for >> encrypted local disk. But given AES hardware speedup, I suspect most >> people can just stay with AES. > > Can you be more

Re: AES leaks, cgd ciphers, and vector units in the kernel

Taylor R Campbell writes: >> Date: Thu, 18 Jun 2020 07:19:43 +0200 >> From: Martin Husemann >> >> One minor nit: with the performance impact that high, and there being >> setups where runtime side channel attacks are totally not an issue, >> maybe we should leave the old code in place for now,

Re: makesyscalls (moving forward)

David Holland writes: > Meanwhile it doesn't belong in sbin because it doesn't require root, > nor does doing something useful with it require root, and it doesn't > need to be on /, so... usr.bin. Unless we think libexec is reasonable, > but if 3rd-party code is going to be running it we really

Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP

Alexander Nasonov writes: > Greg Troxel wrote: >> Kamil Rytarowski writes: >> >> > Is it possible to avoid negation in the name? >> > >> > KAUTH_SYSTEM_ENABLE_SWAP_ENCRYPTION >> >> I think the point is to have one permission to enable

Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP

Kamil Rytarowski writes: > Is it possible to avoid negation in the name? > > KAUTH_SYSTEM_ENABLE_SWAP_ENCRYPTION I think the point is to have one permission to enable it, which is perhaps just regular root, and another to disable it if securelevel is elevated. So perhaps there should be two

Re: Rump makes the kernel problematically brittle

Thor Lancelot Simon writes: > I'd love to see a GSoC project to actually make rump build like the > kernel...but it may be too much work. Good points, and improvement would be great.

Re: Rump makes the kernel problematically brittle

The other side of the coin to "rump is fragile" is "an operating system without rump-style tests that can be run automatically is suscpetible to hard-to-detect failures from changes, and is therefore fragile". There have been many instances (usually on current-users, I think) of reports of

Re: Rump dependencies (5.2)?

Mouse writes: >> The rump build is done with separate reachover makefiles. [...] > > Hm. Then I think possibly the right answer for the moment is for me to > excise rump from my tree entirely. I can't recall ever wanting its > functionality, and trying to figure out what the dependency graph

Re: Proposal, again: Disable autoload of compat_xyz modules

chris...@astron.com (Christos Zoulas) writes: > I propose something very slightly different that can preserve the current > functionality with user action: > > 1. Remove them from standard kernels in architectures where modules are >supported. Users can add them back or just use modules. > 2.

Re: build.sh sets with xz (was Re: vfs cache timing changes)

Martin Husemann writes: > On Fri, Sep 13, 2019 at 06:59:42AM -0400, Greg Troxel wrote: >> I'd like us to keep somewhat separate the notions of: >> >> someone is doing build.sh release >> >> someone wants min-size sets at the expense of a lot of cpu time &

Re: build.sh sets with xz (was Re: vfs cache timing changes)

"Tom Spindler (moof)" writes: >> PS: The xz compression for the debug set takes 36 minutes on my machine. >> We shoudl do something about it. Matt to use -T for more parallelism? > > On older machines, xz's default settings are pretty much unusable, > and USE_XZ_SETS=no (or USE_PIGZGZIP=yes) is

Re: NFS lockup after UDP fragments getting lost

Edgar Fuß writes: > Thanks to riastradh@, this tuned out to be caused by an (UDP, hard) > HFS mount combined with a mis-configured IPFilter that blocked all but > the first fragment of a fragmented NFS reply (e.g., readdir) combined > with a NetBSD design error (or so Taylor says) that a vnode

Re: /dev/random is hot garbage

Taylor R Campbell writes: >> It would also be reasonable to have a sysctl to allow /dev/random to >> return bytes anyway, like urandom would, and to turn this on for our xen >> builders, as a different workaround. That's easy, and it doesn't break >> the way things are supposed to be for people

Re: /dev/random is hot garbage

I don't think we should change /dev/random. For a very long time, the notion is that the bits from /dev/random really are ok for keys, and there has been a notion that such bits are precious and you should be prepared to wait. If you aren't generating a key, you shouldn't read from /dev/random.

Re: mknod(2) and POSIX

David Holland writes: > However, I notice that mknod(2) does not describe how to set the > object type with the type bits of the mode argument, or document which > object types are allowed, and mkfifo(2) also does not say whether > S_IFIFO should be set in the mode argument or not. This is

Re: mknod(2) and POSIX

Agreed with uwe@ about not mixing unrelated changes. Pretend we are using git :-) The patch looks fine. Agreed that making fifos with mknod is an odd thing to do, but if it's in posix, then we should do it unless there's something really bad about supporting the posix usage. In this case, it

mknod(2) and POSIX

I recently noticed that pkgsrc/sysutils/bup failed when restoring a fifo under NetBSD because it calls mknod (in python) which calls mknod(3) and hence mknod(2). Our mknod(2) man page does not mention creating FIFOS, and claims The mknod() function conforms to IEEE Std 1003.1-1990

Re: pool: removing ioff?

Maxime Villard writes: > I would like to remove the 'ioff' argument from pool_init() and friends, > documented as 'align_offset' in the man page. This parameter allows the > caller to specify that the alignment given in 'align' is to be applied at > the offset 'ioff' within the buffer. > > I

Re: patch: debug instrumentation for dev/raidframe/rf_netbsdkintf.c

Christoph Badura writes: > On Mon, Jan 21, 2019 at 04:24:49PM -0500, Greg Troxel wrote: >> Separetaly from debug code being careful, if it's a rule that bdv can't >> be NULL, it's just as well to put in a KASSERT. Then we'll find out >> where that isn't true and c

Re: patch: debug instrumentation for dev/raidframe/rf_netbsdkintf.c

Christoph Badura writes: >> > + if (bdv == NULL) >> > + return 0; >> > + >> >> This looked suspicious, even before I read the code. >> The question is if it is ever legitimate for bdv to be NULL. > > That is an excellent point. The short answer is, no it isn't. And it > never was

Re: patch: debug instrumentation for dev/raidframe/rf_netbsdkintf.c

Christoph Badura writes: > Here is some instrumentation I found useful during my recent debugging. > If there are no objections, I'd like to commit soon. > > The change to rf_containsroot() simplifies the second DPRINTF that I added. > > Index: rf_netbsdkintf.c >

Re: Importing libraries for the kernel

m...@netbsd.org writes: > I don't expect there to be any problems with the ISC license. It's the > preferred license for OpenBSD and we use a lot of their code (it's > everywhere in sys/dev/) Agreed that the license is ok. > external, as I understand it, means "please upstream your changes, and

Re: noatime mounts inhibiting atime updates via utime()

Edgar Fuß writes: >> Honestly, I think atime is one of the dumbest thing ever. > We occasionally use them to find out (or have a first guess at): > -- has anyone used libfoobar last year? > -- who uses kbaz, i.e. has /home/xyz/.config/kbaz.conf been accessed? > > We use snapshots to run backups,

Re: fixing coda in -current

m...@netbsd.org writes: > On Sun, Nov 25, 2018 at 08:05:21PM -0500, Greg Troxel wrote: >> However, I am pleased to report that the coda people have said that they >> are working on a fuse interface, although it's expected to be slower. >> We'll see, both if it mate

Re: fixing coda in -current

m...@netbsd.org (Emmanuel Dreyfus) writes: > Greg Troxel wrote: > >> However, I am pleased to report that the coda people have said that they >> are working on a fuse interface, although it's expected to be slower. > > FUSE vs kernel does not really matter when we deal w

Re: fixing coda in -current

David Holland writes: > So I have no immediate comment on the patch but I'd like to understand > better what it's doing -- the last time I crawled around in it > (probably 7-8 years ago) it appeared to among other things have an > incestuous relationship with ufs_readdir such that if you tried

Re: fixing coda in -current

I volunteer to bug Satya about using FUSE instead of a homegrown (pre-FUSE) kernel interface. I am unaware of anytning else that allows writes while disconnected and reintegrates them. I have actually done that, both on purpose and for several days while my IPsec connection was messed up, and it

Re: fixing coda in -current

I used to use it, and may again. So I'd like to see it stay, partly because I think it's good to keep NetBS relevant in the fileystem research world. I am expecting to see new upstream activity. But, I think it makes sense to remove it from GENERIC, and perhaps have whatever don't-autoload

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

co...@sdf.org writes: > So, I am excluding things that appear in ALL, and I am not checking if But ALL is an x86 thing, currently. > they appear as modules. Interesting, but I suppose they then belong in ALL also. > So far I had complaints about the appearance of 'lm' which cannot be >

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

co...@sdf.org writes: > This is an automatically generated list with some hand touchups, feel > free to do whatever with it. I only generated the output. > > ac100ic > acemidi > acpipmtr > [snip] I wonder if these are candidates to add to an ALL kernel, and if it will turn out that they are

Re: NetBSD-8 kernel too big?

Two thoughts: When trimming, ls -lSr in the kernel build directory will identify large objects. We have had kernel modules for a while, but I'm not entirely clear on where we are. I would think that moving to a mode of aggressively not including things that can be modules and loading

Re: How to prevent a mutex being _enter()ed from being _destroy()ed?

Edgar Fuß writes: > I know very little about locking so that's probably a stupid question, but: Don't worry - locking is probably the hardest thing to get right. > Is there a general scheme/rule/proposal how to prevent a mutex that someone > is trying to mutex_enter() from being teared down

Re: new errno ?

Phil Nelson writes: > Hello, > > In working on the 802.11 refresh, I ran into a new errno code from > FreeBSD: > > #define EDOOFUS 88 /* Programming error */ > > Shall we add this one? (Most likely with a different number since 88 is > taken > in the NetBSD

Re: ./build.sh -k feature request (was Re: GENERIC Kernel Build errors with -fsanitize=undefined option enabled)

[grudgingly keeping tech-kern and current-users both :-] Reinoud Zandijk writes: > @@ -1084,6 +1084,9 @@ Usage: ${progname} [-EhnoPRrUuxy] [-a ar > Should not be used without expert knowledge of the build > system. > -h Print this help message. > -j

Re: i2c and indirect vs. direct config

(I am a noob at i2c.) Your points about explicit config make a lot of sense; reminds me of qbus and isa bus where you have to know. However, baking into the kernel is unfortunate, and I wonder if it makes sense to have the i2c plan either in a boot variable or as something that can configure

Re: cpu1: failed to start (amd64)

It feels to me like you might be having two problems: SMP/cpu and USB. I do not understand if they are related or not. Assuming you have a working netbsd-7 machine (i386 is fine), it might be best to build a netbsd-8 kernel and debug there, since 8 has many fixes since 7. You have built a

Re: Reading a DDS tape with 2M blocks

Edgar Fuß writes: > I have a DDS tape (written on an IRIX machine) with 2M blocks. > Any way to read this on a NetBSD machine? > My memories of SCSI ILI handling on DDS are fuzzy. I remember you can operate > these tapes in fixed or variable block size mode, where some

Re: Merging ugen into the usb stack

Martin Husemann <mar...@duskware.de> writes: > On Mon, Dec 11, 2017 at 08:24:00AM -0500, Greg Troxel wrote: >> I wonder if we should be attaching drivers to endpoints, rather than >> devices. > > This is the drivers decision (we have drivers that do it). > > Ho

Re: Merging ugen into the usb stack

Martin Husemann writes: > However, it can not work with the way NetBSD uses ugen devices: > > uftdi0 at uhub3 port 2 > uftdi0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, > addr 3 > ucom0 at uftdi0 portno 1 > ucom1 at uftdi0 portno 2 > > I can

Re: Proposal: Disable autoload of compat_xyz modules

Manuel Bouyer writes: > On Sun, Sep 10, 2017 at 12:17:58PM +0200, Maxime Villard wrote: >> Re-thinking about this again, it seems to me we could simply add a flags >> field in modinfo_t, with a bit that says "if this module is builtin, then >> don't load it". To use

Re: kernel aslr: someone interested?

Maxime Villard writes: > I would also add - even if it is not a relevant argument - that most > "commonly-used" operating systems do have kernel aslr: Windows, Mac, Linux, > etc. There's another point, which various people may also consider invalid :-) In the US, there's a

Re: spurious DIAGNOSTIC message "no disk label"

I think it's wrong to print out messages like that because DIAGNOSTIC is defined. DIAGNOSTIC is supposed to just add KASSERT (was panic, long ago) about conditions that must be true unless the kernel is buggy. Separately, given that there's no rule that all disks must have labels, it seems

Re: Howto use agr to aggregate VPN tunnels

BERTRAND Joël writes: > Hi, > > I have seen in manual : > > There is no way to configure agr interfaces without attaching physical > interfaces. > > Is tap considered as physical interface or not ? tap has MAC > address thus I think that is not a

Re: CPUs and processes not evenly assigned?!

Hubert Feyrer writes: > On Fri, 11 Nov 2016, Michael van Elst wrote: >> Since we don't have floating point the computation should be done in >> fixed point arithmetic, e.g. >> >> r_avgcount = (A * r_avgcount + B * INT2FIX(r_mcount)) / (A + B); >> >> With the current A=B=1

Re: FUA and TCQ

Johnny Billquist writes: > With rotating rust, the order of operations can make a huge difference > in speed. With SSDs you don't have those seek times to begin with, so > I would expect the gains to be marginal. For reordering, I agree with you, but the SSD speeds are so high

Re: struct file reference at VFS level

Joerg Sonnenberger <jo...@bec.de> writes: > On Fri, Apr 22, 2016 at 10:42:10AM -0400, Greg Troxel wrote: >> I still don't understand why this is about FUSE. What if a file were >> opened without O_NONBLOCK and then the same file were opened with? > > O_NONBLO

Re: struct file reference at VFS level

Emmanuel Dreyfus writes: >> (...) proposed mandatory lock feature checks for locks during >> every data modifying fops. And hence we make use of fd flags too. Let >> me explain the scenario from my test case: >> >> Process 1 opens file 'foo' with O_RDWR and acquires a shared

Re: struct file reference at VFS level

m...@netbsd.org (Emmanuel Dreyfus) writes: > FUSE methods on open files use a pointer on a file handle. The > filesystem uses it to track attribute about the open file. For instance, > if process 1 opens a file with a given flag and process 2 opens it > without it, the filesystem may need to act

  1   2   3   >