Re: Support for 4KB sectors size disk ?

On Jan 12, 2010, at 7:14 AM, Izumi Tsutsui wrote: > > My HP9000/382 has 256bytes/sector SCSI floppy (with FDD-SCSI convertor), > but I don't think it's worth to bother to support it. > (though it might be trivial once we abandon traditional DEV_BSIZE > constant from raw I/O access and all scsipi

Re: >512bytes/sector support (Re: Support for 4KB sectors size disk ?)

On Jan 13, 2010, at 3:57 AM, Izumi Tsutsui wrote: > As I wrote first, we should make a decision of buffercache(9) > and physio(9) APIs for !512bytes/sector disks. > Fixing file systems or disk drivers without it just generates > yet another random inconsisntent patch because there is no "right" f

Re: [PAE support] Types + cosmetic fixes

On Feb 23, 2010, at 7:57 AM, Jean-Yves Migeon wrote: > Yep, i386-pae. IMHO, modules cannot be "safely" shared between PAE and > non-PAE. Why not? -- thorpej

Re: [PAE support] Types + cosmetic fixes

On Feb 24, 2010, at 1:16 AM, Manuel Bouyer wrote: > I'm not sure what the effect to configure and similar scripts would be. > If this is for modules, I think this needs more though. I suspect some > kernel build options can also cause ABI changes which can cause modules > to fail, so modules shou

Re: [PAE support] Types + cosmetic fixes

On Feb 24, 2010, at 4:51 PM, Jean-Yves Migeon wrote: > On 02/25/10 00:42, Jason Thorpe wrote: >> >> On Feb 23, 2010, at 7:57 AM, Jean-Yves Migeon wrote: >> >>> Yep, i386-pae. IMHO, modules cannot be "safely" shared between PAE and >>> non-PAE

Re: [PAE support] Types + cosmetic fixes

On Feb 25, 2010, at 1:49 AM, Manuel Bouyer wrote: > There are ABI differences, in the same way there are ABI differences between > atari and mac68k. Those ABI differences should be considered as bugs. > I'm not sure what is the "ABI to drivers", BTW. AFAIK drivers are not > restricted to a subs

Re: [PAE support] Types + cosmetic fixes

On Feb 26, 2010, at 8:51 AM, Manuel Bouyer wrote: > Yes. modules can use bus_space, or inlines/macros from pmap > (eventually indirectly through e.g. bus_dma). Then we should fix bus_space and bus_dma to avoid exposing those implementation details. > they have, although it would make sense to

Re: [PAE support] Types + cosmetic fixes

On Feb 26, 2010, at 11:07 AM, Manuel Bouyer wrote: > On Fri, Feb 26, 2010 at 10:58:33AM -0800, Jason Thorpe wrote: >>> they have, although it would make sense to make it different. >>> The main problem would be configure scripts that may not parse properly >>> a dif

Re: DTrace FBT provider heads-up

On Mar 12, 2010, at 2:16 PM, Darran Hunt wrote: > This gives us over 29,000 instrumentation points available for tracing with > DTrace. The full argument list is passed to the probe on function entry, and > the return result is passed on exit. Wicked cool. I use DTrace (and the FBT!) a lot i

Re: bus_space_physload(9)

On Mar 24, 2010, at 8:04 AM, Masao Uebayashi wrote: > It's in bus_space(9) because it's API for device drivers. Its behavior needs > UVM's help, of course. Also, because bus-specific code needs to map the bus_space_tag_t + the bus_addr_t into a system physical address. -- thorpej

Re: Patch: new random pseudodevice

On Dec 9, 2011, at 2:38 PM, Steven Bellovin wrote: > Imagine > what would happen if someone upgraded the disk to a flash disk or > one with a large flash cache Heh, I was gonna say -- "I haven't carried around a computer that actually has a hard drive in it for at least a year now." -- tho

kern/53166: NFS default to UDP; it should really default to TCP

Per: http://mail-index.netbsd.org/netbsd-bugs/2018/04/08/msg056464.html I don’t disagree with mlelstv@’s opinion — that TCP is the better choice. (I may be biased.) In any case, would love to clear this change out of my local

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

> On May 11, 2018, at 8:28 AM, Jaromír Doleček > wrote: > > I've modified the uvm_bio.c code to use direct map for amd64. Change > seems to be stable, I've also run 'build.sh tools' to test out the > system, build suceeded and I didn't observe any problems with > stability. Test was on 6-core

Re: CVS commit: src/sys/dev/pci

> On May 16, 2018, at 12:02 PM, Jonathan A. Kollasch > wrote: > > Module Name: src > Committed By: jakllsch > Date: Wed May 16 19:02:00 UTC 2018 > > Modified Files: > src/sys/dev/pci: pci_map.c > > Log Message: > Enable the appropriate memory or I/O space decode in the PCI > C

Re: firefox sandboxing

> On May 14, 2018, at 6:38 AM, Thomas Klausner wrote: > > We already support chroot(2). Are user namespaces > (http://man7.org/linux/man-pages/man7/user_namespaces.7.html - looks > like capabilities) something that would be good to have for NetBSD? IMO, chroot(2) is a pretty poor way to do sa

Re: CVS commit: src/sys/dev/pci

> On May 16, 2018, at 1:07 PM, Jonathan A. Kollasch > wrote: > > I'm a bit uneasy about it myself for that same reason. However, we > do not to my knowledge have the infrastructure available to do a > complete validation of the resource assignment. If we did, we'd be > able to do hot attach

Re: kern/53166: NFS default to UDP; it should really default to TCP

Having heard no objections, I just committed this change. /me raises glass To more reliable NFS mounts! Cheers! > On May 8, 2018, at 5:52 PM, Jason Thorpe wrote: > > Per: http://mail-index.netbsd.org/netbsd-bugs/2018/04/08/msg056464.html > <http://mail-index.netbsd.org/netbsd-

Ambient light sensors in envsys

Hey folks - I have a need to have an ambient light sensor in my silly little clock project. I have a driver for the particular sensor I’m using that runs entirely in user space, but I’m wondering if it might be a good idea to glue it into envsys. There are a couple reasons for putting it into

Re: Ambient light sensors in envsys

> On May 19, 2018, at 4:23 PM, Jason Thorpe wrote: > > have a driver for the particular sensor I’m using that runs entirely in user > space, …in case anyone is curious: https://github.com/thorpej/Electronics/tree/master/Sensors/TSL256x -- thorpej

Re: Revisiting uvm_loan() for 'direct' write pipes

> On May 21, 2018, at 12:49 PM, Jaromír Doleček > wrote: > > Mostly since I want to > have at least one other consumer of the interface before I consider it > as final, to make sure it covers the general use cases. BTW, I was thinking about this, and I think you need to also handle the case

Re: Revisiting uvm_loan() for 'direct' write pipes

> On May 25, 2018, at 1:01 PM, Jaromír Doleček > wrote: > > So, I'm actually thinking to change uvm_loan() to not enforce R/O > mappings and leave page attributes without change. It would require > the caller to deal with possible COW or PG_RDONLY if they need to do > writes. In other words, a

PWM and user space API

I’m going to be writing a driver for the NXP PCA9685, and want to glue it into the PWM kernel API jmcneill@ added… but I have a bunch of uses for this device that won’t really be covered by FDT, so I think there needs to be some sort of user space API as well. I have to say that I’m growing fru

Re: PWM and user space API

> On May 28, 2018, at 11:09 AM, Jason Thorpe wrote: > > I’m going to be writing a driver for the NXP PCA9685, and want to glue it > into the PWM kernel API jmcneill@ added… but I have a bunch of uses for this > device that won’t really be covered by FDT, so I think there n

Re: PWM and user space API

> On May 28, 2018, at 2:43 PM, Jason Thorpe wrote: > > The PCA9685 also doesn’t have a variable clock UNLESS it’s driven by an > external clock source, in which case a pre-scaler value can be applied > (though, I’m not 100% certain on this — need to re-read the data sheet).

Re: i2c and indirect vs. direct config

> On May 30, 2018, at 12:47 AM, Martin Husemann wrote: > > To avoid this indirect config fallback, Jared disabled this > for all i2c controllers FDT knows about, assuming it would be > easy to just fix FDT instead. To be clear — Indirect-config wasn’t disabled by setting the i2c-indirect-co

Re: i2c and indirect vs. direct config

> On May 30, 2018, at 11:54 AM, Brad Spencer wrote: > Does the techniques mentioned in these offer any hope of determining the > presence of an actual device at a particular address on the bus in a > harmless manor: > > http://forum.arduino.cc/index.php?topic=61520.0 > https://electronics.sta

Re: i2c and indirect vs. direct config

> On May 30, 2018, at 4:42 PM, Brad Spencer wrote: > > Jason Thorpe writes: > >>> On May 30, 2018, at 11:54 AM, Brad Spencer wrote: > > A zero length write would probably also work and should be just as safe, > although I am not sure that every i2c controller

Re: i2c and indirect vs. direct config

> On May 31, 2018, at 6:14 PM, Brad Spencer wrote: > > I note that the gpioow, a onewire bus, may have simular ghost issues as > i2c: It’s literally impossible to probe for devices on raw GPIO — we really should do hard-and-fast locators in that scenario. -- thorpej

Re: i2c and indirect vs. direct config

> On May 31, 2018, at 6:14 PM, Brad Spencer wrote: > > Unfortunate behavior. Looking back over the sensor driver I worked on, > it appears that I always read something to determine if the device was > actually there. I spent some time reviewing NXP’s i2c spec this evening (well, during timeo

Re: i2c and indirect vs. direct config

> On May 31, 2018, at 6:14 PM, Brad Spencer wrote: > > I wonder if the i2c bus attachments should have the option of being > treated like gpio attachements with a new command... probably a lot of > work: > > iicctl iic2 attach dstrc 0x68 3231 I’ve been thinking about this. I think we could

Re: i2c and indirect vs. direct config

> On May 31, 2018, at 9:34 PM, Jason Thorpe wrote: > > I spent some time reviewing NXP’s i2c spec this evening (well, during > timeouts, etc. — GO DUBS), and I’m becoming convinced that there is a subtle > error in our i2c_bitbang code… *smacks forehead* … RPI, of course, ha

Re: i2c and indirect vs. direct config

> On Jun 1, 2018, at 3:45 PM, Paul Goyette wrote: > > On Thu, 31 May 2018, Jason Thorpe wrote: > >> I spent some time reviewing NXP’s i2c spec this evening (well, during >> timeouts, etc. — GO DUBS), and I’m becoming convinced that there is a subtle >> erro

Re: i2c and indirect vs. direct config

> On Jun 1, 2018, at 3:45 PM, Paul Goyette wrote: > > There is at least one i2c bus controller that explicitly doesn't handle > "quick" transactions - the imc controller built into the Intel X99 chip-set. > The docs are pretty clear that it implements an absolute minimum subset of > i2c, j

Re: i2c and indirect vs. direct config

> On Jun 2, 2018, at 2:07 PM, Paul Goyette wrote: > > There's the "minimal-functionality" controller that sits on the "system > management PCI bus" and driven by the imc/imcsmb driver. OMG, what a dumpster fire. Geez, if they were going to to for minimal functionality, why even bother with

Re: i2c and indirect vs. direct config

> On Jun 3, 2018, at 7:30 AM, Thor Lancelot Simon wrote: > > On Sat, Jun 02, 2018 at 03:51:07PM -0700, Jason Thorpe wrote: >> >>> On Jun 2, 2018, at 2:07 PM, Paul Goyette wrote: >>> >>> There's the "minimal-functionality" control

Re: i2c and indirect vs. direct config

> On Jun 4, 2018, at 2:47 PM, Jason Thorpe wrote: > > > >> On Jun 3, 2018, at 7:44 AM, Jason Thorpe wrote: >> >> Actually, I am thinking more of a set of properties that control the >> behavior of the generic i2c code: > > To follow-up, I t

Re: i2c and indirect vs. direct config

> On Jun 3, 2018, at 7:44 AM, Jason Thorpe wrote: > > Actually, I am thinking more of a set of properties that control the behavior > of the generic i2c code: To follow-up, I think I have this sorted out. There were a couple of other issues with how indirect-config was taking

Re: i2c and indirect vs. direct config

On Jun 5, 2018, at 1:19 AM, Paul Goyette wrote:I think I like this approach.But I'm unclear on how/where the i2c-SMBus device's property-list getsset in the first place.For modular drivers loaded from the file-system after the system is upand running, there is a module prop-list

Re: i2c and indirect vs. direct config

> On Jun 5, 2018, at 6:05 AM, Jason Thorpe wrote: > > Anyway, I haven’t even compiled this patch yet, but at least you’ll get the > idea… Indeed, there was a typo in it, but the rest of it stands :-) -- thorpej

Re: i2c and indirect vs. direct config

> On Jun 5, 2018, at 9:21 AM, Jason Thorpe wrote: > > > >> On Jun 5, 2018, at 6:05 AM, Jason Thorpe > <mailto:thor...@me.com>> wrote: >> >> Anyway, I haven’t even compiled this patch yet, but at least you’ll get the >> idea… > > >

Re: i2c and indirect vs. direct config

> On Jun 6, 2018, at 10:21 AM, Jason Thorpe wrote: > > Turns out there are quite a few bugs in the bcm2835 i2c driver as well, that > tripped up my testing, so I’m going to have to spend a few more evenings on > it, sigh. Well, I managed a minimal change to prevent the infi

More i2c auto configuration improvements

I’ve gone through all of the i2c drivers I can find in the source tree and audited their auto configuration scheme. Each of the drivers has been updated to return the “match quality” values introduced in the previous set of changes. To review, those “match quality” values are: — Address-only:

Re: More i2c auto configuration improvements

> On Jun 14, 2018, at 3:12 PM, Paul Goyette wrote: > > BTW, why do you use > > return (0); > > in some of the drivers, while others use > > return 0; > > ? > > Shouldn't we standardise on one or the other? I think it boils down to which lines I typed myself :-) (I tend to pr

Re: urtwn driver is spammy

I’m currently doing some work on the urtwn driver to address some problems in my local setup - stay tuned. -- thorpej Sent from my iPhone. > On Jun 28, 2018, at 3:49 AM, Benny Siegert wrote: > > On Thu, Jun 28, 2018 at 12:47 PM Radoslaw Kujawa > wrote: >> >> >> >>> On 28 Jun 2018, at 12:35

Re: CVS commit: src/sys/kern

> On Jul 1, 2018, at 2:48 AM, Martin Husemann wrote: > > I'd rather not have this at all - instead just drop the useless timestamps > at boot time, they are useless here and make console output unreadable. > > They are fine after mountroot, but is there really any use for them before? +1 --

Re: usb_rem_task_wait

> On Jun 30, 2018, at 11:58 PM, Taylor R Campbell > wrote: > > The attached patch implements usb_rem_task_wait and uses it in various > drivers' detach routines so that they have a chance of guaranteeing > not to leave pending tasks floating around using memory after free. > Also changes vari

Re: usb_rem_task_wait

If you have a newer draft handy, would definitely be interested in looking at it. -- thorpej Sent from my iPhone. On Jul 1, 2018, at 8:18 AM, Taylor R Campbell wrote: >> Date: Sun, 01 Jul 2018 08:02:11 -0700 >> From: Jason Thorpe >> >> I've been thinking abo

Re: usb_rem_task_wait

> On Jul 1, 2018, at 8:18 AM, Taylor R Campbell > wrote: > >> Date: Sun, 01 Jul 2018 08:02:11 -0700 >> From: Jason Thorpe >> >> I've been thinking about this interface a bit... it would be handy >> to have a version of it for some non-usb

Re: mutex question

> On Jul 6, 2018, at 4:48 PM, Phil Nelson wrote: > > Hello, > >The FreeBSD 802.11 code is using a call to mtx_sleep(). The define is: > > #define mtx_sleep(chan, mtx, pri, wmesg, timo) \ >_sleep((chan), &(mtx)->lock_object, (pri), (wmesg), \

Re: new errno ?

> On Jul 6, 2018, at 2:49 PM, Eitan Adler wrote: > > For those interested in some of the history: > https://lists.freebsd.org/pipermail/freebsd-hackers/2003-May/000791.html > ...and the subsequent thread went just as I

Re: CVS commit: src/sys/arch/x86/x86

> On Jul 8, 2018, at 6:30 AM, Kamil Rytarowski wrote: > > In future __NO_STRICT_ALIGNMENT could be defined for aarch64, at least > for the use of acpica (which still contains a fallback for Itanium > without misaligned access, but not actively maintained). > > Linux uses a different approach

Re: Too many PMC implementations

Speaking as someone who was peripherally involved in the PMC flavor below, I have no objections to this. > On Jul 11, 2018, at 9:22 AM, Maxime Villard wrote: > > Right now we have three (or more?) different implementations for Performance > Monitoring Counters: > > * PMC: this one is MI. It is

Re: Removing dbregs

> On Jul 13, 2018, at 12:31 PM, Maxime Villard wrote: > > So why not remove the code? No objection from me. -- thorpej

Re: Removing dbregs

> On Jul 13, 2018, at 2:22 PM, Kamil Rytarowski wrote: > > On 13.07.2018 23:10, Jaromír Doleček wrote: >> 2018-07-13 22:54 GMT+02:00 Kamil Rytarowski : >>> I disagree with disabling it. The code is not broken, it's covered by >>> tests, it's in use. >> >> This looks like perfect candidate for

Re: ioctl(2) numbers

> On Aug 1, 2018, at 2:56 AM, Robert Swindells wrote: > > > Does it matter if ioctl(2) numbers overlap so long as they are in > different groups ? It's perfectly fine. They simply need to be unique within the group. -- thorpej

Re: NetBSD/usermode link issues

> On Aug 4, 2018, at 7:45 AM, Reinoud Zandijk wrote: > > Hi folks, > > as you might know, i'm currently working on NetBSD/usermode.amd64 but I can > use some help with the following linking issue: NetBSD/usermode seems a little wacky in that it's intended to run on some host system, right?

Re: Proposal: rename min/max -> umin/umax

> On Aug 5, 2018, at 9:32 AM, Taylor R Campbell > wrote: > > I propose we rename libkern's min/max to umin/umax. The names min and > max invite general use like MIN and MAX, but these functions truncate > their arguments to unsigned first. We also have imin/imax, lmin/lmax, > and ulmin/ulma

Re: 8.0 performance issue when running build.sh?

> On Aug 6, 2018, at 12:17 PM, Rhialto wrote: > > 21.96 24626 82447.93 kernel_lockip_slowtimo+1a The work that's happening here looks like a scalability nightmare., regardless of holding the kernel lock or not. A couple of things: 1- It should do a better job of determining

Re: mutex_oncpu() called on destroyed mutex? (was: repeated panics in mutex_vector_enter (from unp_thread))

> On Aug 7, 2018, at 9:44 AM, Edgar Fuß wrote: > > I observe this on 6.1, but I can't see the relevant code changed in current. > > mutex_vector_enter() does (-current uses KPREMPT_* macros) > > do { > kpreempt_enable(); > SPINLOCK_BACKOFF(count); >

Re: 8.0 performance issue when running build.sh?

> On Aug 9, 2018, at 10:40 AM, Thor Lancelot Simon wrote: > > Actually, I wonder if we could kill off the time spent by fileassoc. Is > it still used only by veriexec? We can easily option that out of the build > box kernels. Indeed. And there are better ways to do what veriexec does, in an

Re: Too many PMC implementations

> On Aug 17, 2018, at 8:42 AM, Kamil Rytarowski wrote: > > Speaking realistically, probably all the recent software-based kernel > profiling was done with DTrace. Yah, I suppose I'm okay will killing off kernel GPROF support ... you can essentially do the same-thing-but-better with an on-cpu

Re: Too many PMC implementations

> On Aug 23, 2018, at 8:47 AM, Anders Magnusson wrote: > I have used it not long ago for vax. Maybe I did have to do some tweaks, do > not remember, > but I really want to be able to use kernel profiling on vax. > > So, I really oppose removing it and leaving vax without any kernel profiling

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

> On Nov 12, 2018, at 11:12 AM, John Nemeth wrote: > > wbsio and wt also seems to fit in that category. Isn't "wt" an ancient PC tape drive? We should make an effort to prune more deadwood drivers. -- thorpej

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

FWIW, it's not a great idea to throw all of the i2c drivers into a kernel what will ever be booted, because of the i2c address assignment situation. > On Nov 12, 2018, at 2:15 PM, Brad Spencer wrote: > > > co...@sdf.org writes: > >> This is an automatically generated list with some hand touch

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

> On Nov 12, 2018, at 1:59 PM, John Nemeth wrote: > > On Nov 12, 1:16pm, Jason Thorpe wrote: > } Subject: Re: Things not referenced in kernel configs, but mentioned in fil > } > On Nov 12, 2018, at 11:12 AM, John Nemeth wrote: > } > > } > wbsio and wt also

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

> On Nov 13, 2018, at 7:15 AM, John Nemeth wrote: > > That's a different kind of unusable. :-) That puts it in > the same camp as strip, where there may be functioning hardware, > but you can't do anything with the hardware. ...and when you can't do anything with the hardware, people do

Re: API change request. Was => Re: Time accounting on statclock()

> On Nov 18, 2018, at 11:00 AM, Martin Husemann wrote: > > On Sun, Nov 18, 2018 at 04:19:50PM +0530, Cherry G.Mathew wrote: >> Typo: >> https://mail-index.netbsd.org/source-changes/2018/11/18/msg100702.html > > Ugh - can't you just modify > > CLKF_USERMODE(frame) > CLKF_PC(frame) > CLKF_INTR

Re: fixing coda in -current

> On Nov 20, 2018, at 9:55 AM, Brett Lymn wrote: > > Comments? Anyone really care? Honestly, I think we should probably remove it. -- thorpej

Re: New i2clcd PCF8754 i2c lcd interface module driver

Cool. I think i2clcd is too generic of a name, though, in the event there are other i2c-connected displays that aren't software-compatible with this one. (I have a couple that I'm going to get around to playing with, and not 100% certain they're compatible with this one.) > On Nov 21, 2018, at

Re: New i2clcd PCF8754 i2c lcd interface module driver

> On Nov 21, 2018, at 10:07 AM, Jason Thorpe wrote: > > Cool. I think i2clcd is too generic of a name, though, in the event there > are other i2c-connected displays that aren't software-compatible with this > one. > > (I have a couple that I'm going to get

Tidy up / simplify "com" register initialization

I'm working on an application where I need some additional run-time flexibility in how the "com" driver register map is setup. COM_REGMAP cam do the job, but there is some untidiness around how com_regs is initialized. This patch is a small step in cleaning that up, with some other minor chang

Re: noatime mounts inhibiting atime updates via utime()

> On Dec 4, 2018, at 8:12 PM, Robert Elz wrote: > > I'd probably change it more to be "do it when explicitly asked to, > or whenever the inode is being updated for other reasons and an > atime update could be made" - that is "unless instructed, don't do > inode updates that update nothing but

Re: Tidy up / simplify "com" register initialization

> On Dec 5, 2018, at 12:00 AM, Masanobu SAITOH wrote: > > On 2018/12/04 13:53, Jason Thorpe wrote: >> I'm working on an application where I need some additional run-time >> flexibility > > PLEASE! > sys/dev/ic/com.c has some compile time #ifdef 's and

Re: enhance sysctl kern.expose_address

> On Dec 5, 2018, at 8:27 AM, Christos Zoulas wrote: > > > This patch: > > https://www.netbsd.org/~christos/kmem_expose_address.diff PK_KMEM should only be set if mm_open returns 0. There's a case where mm_md_open can return an error and PK_KMEM is still set. -- thorpej

Re: enhance sysctl kern.expose_address

> On Dec 5, 2018, at 8:38 AM, Jason Thorpe wrote: > > > >> On Dec 5, 2018, at 8:27 AM, Christos Zoulas wrote: >> >> >> This patch: >> >> https://www.netbsd.org/~christos/kmem_expose_address.diff > > PK_KMEM should only be set if

Re: enhance sysctl kern.expose_address

> On Dec 5, 2018, at 8:38 AM, Jason Thorpe wrote: > > > >> On Dec 5, 2018, at 8:27 AM, Christos Zoulas wrote: >> >> >> This patch: >> >> https://www.netbsd.org/~christos/kmem_expose_address.diff > > PK_KMEM should only be set if

Re: enhance sysctl kern.expose_address

> On Dec 5, 2018, at 8:54 AM, Christos Zoulas wrote: > > On Dec 5, 8:45am, thor...@me.com (Jason Thorpe) wrote: > -- Subject: Re: enhance sysctl kern.expose_address > > | ...also it looks like the kauth callback doesn't handle the "2" case of > | &quo

Re: libnv

> On Aug 27, 2018, at 7:49 AM, Mindaugas Rasiukevicius wrote: > I do not think there was any conclusion either, or a conclusion that > we always want to have static serialisation with a schema (IMO, there > are pros and cons in both cases). Worth noting that there are multiple > libraries alr

Re: libnv

> On Aug 27, 2018, at 2:25 PM, David Holland wrote: > > On Mon, Aug 27, 2018 at 08:41:43AM -0700, Jason Thorpe wrote: >>> [proplib] >> >> Let me try to address these points one by one: > > Now that you're back, can you explain a few more basic po

Re: Concurrent trie-hash map

> On Oct 16, 2018, at 1:00 PM, Mindaugas Rasiukevicius wrote: > > Hi, > > I recently implemented thmap [1] -- a concurrent trie-hash map, combining > the elements of hashing and radix trie. It is supports lock-free lookups > and concurrent inserts/deletes. It is designed to be optimal as a

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

> On Dec 12, 2018, at 11:46 AM, Michał Górny wrote: > > c. Add an extra flag to va_vaflags that explicitly indicates timestamps > are supposed to be changed; always ignore tv_sec when it's unset, > otherwise respect tv_sec independently of value. This is part of a bigger problem with how the V

Re: Importing libraries for the kernel

> On Dec 14, 2018, at 6:19 AM, Joerg Sonnenberger wrote: > Asymmetrical cryptography is slow and complex. On many architectures, > the kernel will only be able to use slower non-SIMD implementations. ECC > still easily requires 10k cycles per operation. The implementation is > non-trivial in t

Re: CVS commit: src/sys/dev/i2c

> On Dec 14, 2018, at 2:05 PM, Michael Lorenz wrote: > > Module Name: src > Committed By: macallan > Date: Fri Dec 14 22:05:36 UTC 2018 > > Modified Files: > src/sys/dev/i2c: ds1307.c files.i2c > > Log Message: > add options DSRTC_YEAR_START_2K for machines which use 2000 and

Re: [uvm_hotplug] Fixing the build of tests

> On Dec 15, 2018, at 12:51 AM, matthew green wrote: > > we have a general problem in UVM we need to confront some time > fairly soon. it won't be easy to find all the places, and it > won't be easy to test we have found them. > > almost all the page counts in UVM are "int". that overflows

Re: [uvm_hotplug] Fixing the build of tests

> On Dec 15, 2018, at 1:53 PM, Jaromír Doleček > wrote: > > Bigger physical pages also reduce size of page tables (big deal if it > e.g. allows to reduce e.g. 4-level to 3-level mapping, but even "just" > factor or two or four is very good) and hence speed up page faults, > and improve TLB ut

Re: [uvm_hotplug] Fixing the build of tests

> On Dec 16, 2018, at 4:03 PM, matthew green wrote: > > unfortunately, UVM has no good mechanism for dealing with > large page sizes and AFAICT, netbsd only uses them for > unmanaged mappings for kernels (and thus, is entirely MD > in implementation and use), and we don't try to keep > large-p

Re: svr4, again

> On Dec 17, 2018, at 2:00 PM, Maxime Villard wrote: > > Now I'm re-putting the subject on the table, because, as if it wasn't > already glaringly obvious, COMPAT_SVR4 is broken beyond repair. I keep > unintentionally finding bugs in it, and it just doesn't make any sense > to keep it to me.

Re: svr4, again

> On Dec 18, 2018, at 4:16 AM, Maxime Villard wrote: > > Judging by the configuration files: > > * COMPAT_SVR4 is available on sparc, sparc64, *68k, sun2, sun3, atari, > hp300, amiga. This is in terms of files.svr4 inclusions. I suspect that > a part of these inclusions were added automat

Re: svr4, again

> On Dec 18, 2018, at 12:39 AM, Maxime Villard wrote: > > I've made one: > > http://wiki.netbsd.org/attic_museum/ > > I took the entries from src/doc/CHANGES. This is great, thanks. -- thorpej

Re: svr4, again

> On Dec 19, 2018, at 1:48 PM, Johnny Billquist wrote: > > Unless I remember wrong, it's needed for Ultrix compatibility on VAX (and > maybe MIPS?). Ultrix compatibility is handled with COMPAT_ULTRIX, which is more or less vanilla 4.3BSD, with a few extra random things. It, like COMPAT_SUN

Re: svr4, again

> On Dec 19, 2018, at 3:38 PM, Jason Thorpe wrote: > > Ultrix compatibility is handled with COMPAT_ULTRIX, which is more or less > vanilla 4.3BSD, with a few extra random things. It, like COMPAT_SUNOS, is a > pretty thin layer, but also of questionable utility these days

Re: svr4, again

> On Dec 19, 2018, at 5:06 PM, matthew green wrote: > > i would argue that until we're willing to drop a.out exec > entirely we should keep the above. let's not chip and hack > around it. Fair point. Insert "should we get rid of a.out exec, too?" here :-) -- thorpej

Re: svr4, again

5:18:15PM -0800, Jason Thorpe wrote: >>> i would argue that until we're willing to drop a.out exec >>> entirely we should keep the above. let's not chip and hack >>> around it. >> >> Fair point. Insert "should we get rid of a.out exec, too?" here :-) > > No... > > -- > David A. Holland > dholl...@netbsd.org

Re: svr4, again

> 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.

Re: svr4, again

> On Dec 20, 2018, at 12:29 PM, Maxime Villard wrote: > So, first things first, and to come back to my email about ibcs2: what are > the reasons for keeping it? As I said previously, this is not for x86 but > for Vax. As was also said, FreeBSD removed it just a few days ago. > > I'm bringing

Re: svr4, again

> On Dec 20, 2018, at 9:34 AM, Terry Moore wrote: > > Nothing as nice as Franz Lisp. Internal little utilities for which we don’t > have source handy and/or we're too lazy to rebuild. I have a (licensed) > version of Unipress Emacs, but I finally gave up and rebuilt that around the > 5.0 tr

Re: svr4, again

> On Dec 20, 2018, at 2:36 PM, matthew green wrote: > > netbsd had ELF ports before 1.5. i forget when, but at > least alpha and maybe mips were ELF before i386/sparc's > conversion from a.out in 1.5. Yah, I think Alpha was ECOFF **very briefly**, but went ELF pretty quick. -- thorpej

Current best practice for testing a new kernel API?

Howdy folks -- I'm currently working on whipping riastradh@'s threadpool / taskqueue draft implementations into shape. I wrote a simple test jig that lets me exercise the threadpool API from user space, in isolation (i.e. without depending on any users-of-threadpool), but I'm looking for guida

Re: Current best practice for testing a new kernel API?

> On Dec 23, 2018, at 8:41 AM, Christos Zoulas wrote: > > Some ideas: > - kernel module to load the test > - use rump It's almost noon where you are, Christos, but I'm not sure you've had your coffee yet -- that's essentially what I said in my email. :-) Anyway, one drawback of

Re: Current best practice for testing a new kernel API?

> On Dec 23, 2018, at 9:34 AM, Martin Husemann wrote: > >> For completeness, I'll explore the rump option > > That is definitively the prefered way. One example is npf usint it to > test custom kernel test code, but that overall is a bit ... complex. A downside I see to the rump option... as

  1   2   3   4   5   >