> On Sep 12, 2021, at 8:17 AM, Jason Thorpe wrote:
>
> Doing this with symbols is a mess.
Here’s a way to basically get most of what you want without referencing symbols:
struct device_call_generic {
const char *name;
void *args;
};
int device_call_generic
> On Sep 12, 2021, at 1:58 AM, Taylor R Campbell
> wrote:
>
> Why is this a requirement/problem?
>
> The current mechanism still needs space in the kernel for the text of
> the name (the string "i2c-enumerate-devices"). Why refuse to expose
> that name to the linker so it can detect typos
> On Sep 11, 2021, at 4:29 PM, Taylor R Campbell
> wrote:
>
> Here's another sketch that is much more flexible and general.
> Adapting it to link sets should be easy; the main point is that the
> only untyped parts going through void * are limited to the definition
> site of a generic
For a few months now, I've been working on improving the auto configuration of
I2C and SPI devices. These busses, of course, are not self-enumerating, and
besides indirect configuration of devices listed in a kernel config file,
enumerating based on information in platform config data (e.g.
> On Aug 22, 2021, at 9:28 AM, Taylor R Campbell
> wrote:
>
>> As for the way device_call() works, propose an alternative with the
>> following attributes: [...]
>
> Here's a sketch of a typed version of what I think is essentially the
> same thing the untyped device_call does:
>
> typedef
> On Aug 21, 2021, at 2:09 AM, Taylor R Campbell
> wrote:
>
> I read the man page, and...I'm more confused now than I was before.
This isn’t exactly a difficult concept to grasp. I’m honestly baffled at your
confusion.
> 1. Who defines properties? Who is the naming authority that a
> On Aug 15, 2021, at 11:58 AM, Jason Thorpe wrote:
>
>
> [devhandle stuff]
>
> (Yes, I really need to write a man page for it.)
>
> -- thorpej
https://www.netbsd.org/~thorpej/devhandle.9
https://www.netbsd.org/~thorpej/device.9
Note that som
> On Aug 13, 2021, at 7:10 PM, Jason Thorpe wrote:
>
> The API I’m proposing unifies these two domains. By default, getting a
> property will fall through to the “lower layer” (the device tree), unless a
> property has been explicitly set by software, in which
> On Aug 16, 2021, at 9:11 AM, Michael van Elst wrote:
>
> On Mon, Aug 16, 2021 at 06:46:17AM -0700, Jason Thorpe wrote:
>>
>>> On Aug 16, 2021, at 2:31 AM, Michael van Elst wrote:
>>> Isn't that what we do today? Have a common name and value format,
&
> On Aug 16, 2021, at 2:31 AM, Michael van Elst wrote:
>
> j...@coris.org.uk (Julian Coleman) writes:
>
>> We can decide on the name that we'll use (e.g. `ethernet_address') and
>> use that in all the drivers.
>
> Isn't that what we do today? Have a common name and value format,
>
> On Aug 15, 2021, at 6:18 PM, David Holland wrote:
>>
>> This complaint is at best tangentially related to the topic at
>> hand, and can be adjusted separately from this discussion.
>
> Sure, but let's not forget to, ok? I was also not entirely pleased by
> seeing new untyped things going in
> On Aug 15, 2021, at 9:56 AM, Taylor R Campbell
> wrote:
>
> Cool, thanks! Can you expand on what it would look like instead with
> the new API? Do you have any diffs to particulary compelling messy
> drivers or buses to show off how this makes things better?
Here’s a pretty solid
> On Aug 15, 2021, at 9:56 AM, Taylor R Campbell
> wrote:
>
>> Date: Sun, 15 Aug 2021 09:10:48 -0700
>> From: Jason Thorpe
>>
>>> On Aug 15, 2021, at 2:08 AM, Taylor R Campbell
>>> wrote:
>>>
>>> This is a little abs
> On Aug 15, 2021, at 9:30 AM, Michael wrote:
>
> Does this append a NUL if the property doesn't have one?
> IIRC OpenFirmware can be a bit inconsistent with that, I remember doing
> things like zeroing the buffer, then requesting buffer_size - 1 from
> OF_getprop() to make sure the result is
> On Aug 15, 2021, at 2:08 AM, Taylor R Campbell
> wrote:
>
>> Date: Fri, 13 Aug 2021 19:10:20 -0700
>> From: Jason Thorpe
>>
>> Over the last year or so, I've been playing around with ideas for a
>> generic device properties API, and have be
> On Aug 14, 2021, at 1:19 AM, Thomas Klausner wrote:
>
> Hi Jason!
>
> Some minor comments:
Hey Thomas, thanks for the feedback! Responses inline.
> Should we use ssize_t instead of int for the size of objects (or -1 if
> not existing)? I think it's the more appropriate type; on the
Over the last year or so, I’ve been playing around with ideas for a generic
device properties API, and have been slowly adding some infrastructure to the
kernel to enable it. Enough of the infrastructure is now in place (or in the
pipeline) and I think my design is now fully-formed enough in
> On Aug 7, 2021, at 8:59 AM, Robert Elz wrote:
>
> Is there something in the C definition of such things which guarantees
> that the un-init'd fields all get set to 0/NULL ?
Yes, as part of designated initializers in C, omitted fields are initialized in
the same manner as static storage.
> On Aug 7, 2021, at 8:12 AM, Taylor R Campbell
> wrote:
>
>> Date: Wed, 4 Aug 2021 17:52:46 -0700
>> From: Jason Thorpe
>>
>>> On Aug 1, 2021, at 11:10 AM, Martin Husemann wrote:
>>>
>>> On Sun, Aug 01, 2021 at 07:57:20AM -0700, Jason
[Cross-posted to tech-userlevel because this is primarily about an API exposed
to user-space.]
This past winter, I wrote NetBSD native implementations of the Linux timerfd[1]
and eventfd[2] APIs, mainly to fill out gaps in COMPAT_LINUX. Of course, I
wanted to write ATF unit tests for them, so
> On Aug 5, 2021, at 6:22 AM, nia wrote:
>
> I think we should:
>
> (a) introduce SOL_LOCAL to sys/un.h as an alias for 0, as in FreeBSD
> (b) document it
> (c) update all in-tree users of Unix-domain socket options to use
> SOL_LOCAL instead of hardcoding 0
>
Agreed. Patch looks good to
> On Aug 4, 2021, at 10:19 PM, David Holland wrote:
>
> Seems like a definite improvement as long as .submatch and whatnot are
> typed (and not (void *)).
Yes, they’re typed.
-- thorpej
> On Aug 1, 2021, at 11:10 AM, Martin Husemann wrote:
>
> 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 de
> On Aug 1, 2021, at 1:56 PM, Mouse wrote:
>
>>> config_found(CF_VERSION, self, whatever, (const struct cfargs *){
>>> .search = ...,
>>> .locators = ...,
>>> })
>
>> What do you propose should be the behavior if the versions don't match? I h$
>
> I thought the
> On Aug 1, 2021, at 12:48 PM, David Brownlee wrote:
>
> On Sun, 1 Aug 2021 at 15:57, Jason Thorpe wrote:
>>
>>> On Aug 1, 2021, at 5:15 AM, Martin Husemann wrote:
>>>
>>> On Mon, May 10, 2021 at 10:30:09PM -0700, Jason Thorpe wrote:
>>>
> On Aug 1, 2021, at 5:15 AM, Martin Husemann wrote:
>
> 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.
>>
> On Jul 25, 2021, at 1:58 AM, Martin Husemann wrote:
>
> 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_c
Background: The kernel mutex implementation has a pretty generic implementation
that can be used on any platform that can provide a pointer-sized atomic
compare-and-swap primitive. Platforms provide a definition of MUTEX_CAS() that
expands to the right thing for that platform.
For the most
> On Jul 14, 2021, at 9:14 PM, Paul Goyette wrote:
>
> Seems to me the best/safest thing to do for now would be to prohibit
> the extended-attr on devices and fifos.
That seems at best a sort-term workaround, but perhaps warranted to eliminate
the data corruption issue.
-- thorpej
> On Jun 25, 2021, at 4:10 AM, nia wrote:
>
> hi tech-kern,
>
> The uscanner driver only exists for compatibility with userspace Linux
> software that uses an interface that was already deprecated by Linux
> in 2004. All scanner software these days uses ugen.
>
> I think we should remove
> On May 27, 2021, at 6:17 AM, Jason Thorpe wrote:
>
>>
>> On May 27, 2021, at 3:35 AM, Taylor R Campbell
>> wrote:
>>
>>> Date: Wed, 26 May 2021 19:46:57 -0700
>>> From: Jason Thorpe
>>>
>>> The test program sets up a SI
> On May 27, 2021, at 6:29 AM, Jason Thorpe wrote:
>
>
>> On May 27, 2021, at 3:35 AM, Taylor R Campbell
>> wrote:
>>
>> The default exception handling defined in IEEE 754-2019 precisely
>> defines what the results of the operation should be, so ther
> On May 27, 2021, at 3:35 AM, Taylor R Campbell
> wrote:
>
> The default exception handling defined in IEEE 754-2019 precisely
> defines what the results of the operation should be, so there's no
> semantic ambiguity about what the program should observe when it
> proceeds on return from the
> On May 26, 2021, at 8:14 PM, Mouse wrote:
>
>> But the x86_64 code appears to return to the same instruction, banging its h$
>
>> It's my belief that the alpha behavior is more desirable.
>
>> Please, discuss.
>
> I could argue that either way.
>
> In some cases, you want to re-execute
> On May 27, 2021, at 3:35 AM, Taylor R Campbell
> wrote:
>
>> Date: Wed, 26 May 2021 19:46:57 -0700
>> From: Jason Thorpe
>>
>> The test program sets up a SIGFPE handler, and the handler make a
>> copy of the siginfo, sets a global flag, and return
I've been working on fixing some test case failures on the Alpha port, and I'm
elbow-deep in FP-land right now. The Alpha has a somewhat complicated FP story
because it has architecture-mandated software completion for essentially
anything outside the happy path in hardware, and to support
> 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 am not a fan of Taylor's proposals. Concrete
proposals welcome.
--
> On Apr 25, 2021, at 4:26 AM, Taylor R Campbell
> wrote:
>
>> Date: Sat, 17 Apr 2021 17:10:44 -0700
>> From: Jason Thorpe
>>
>> These changes simplify the API by removing a jumble of
>> config_{search,found}_this_that_and_the_other_thing() and goi
I’ve been noodling on some changes to the autoconfiguration APIs on the
“thorpej-cfargs” branch for a little bit now, and I think it’s ready to merge
in. These changes simplify the API by removing a jumble of
config_{search,found}_this_that_and_the_other_thing() and going back to just
having
> On Mar 26, 2021, at 12:58 PM, Rhialto wrote:
>
> On Wed 24 Mar 2021 at 13:37:53 -0700, Jason Thorpe wrote:
>
> [ explanation of direct and indirect configuration ]
>
> Is there any reason why it's called direct and indirect? I can't really
> match those names to th
man
> page?
>
>
> On Wed, 24 Mar 2021, Jason Thorpe wrote:
>
>> There appears to be come inconsistency and/or confusion regarding the usage
>> of the “locators” argument passed to the (*ca_rescan)() functions.
>>
>> Background: drochner@ added this res
There appears to be come inconsistency and/or confusion regarding the usage of
the “locators” argument passed to the (*ca_rescan)() functions.
Background: drochner@ added this rescan mechanism back in 2004 to support
driver modules providing cfdata, to facilitate correct device->driver matching
> On Feb 19, 2021, at 5:33 AM, Greg Troxel wrote:
>
> I thought NCQ was supposed to give acks for actual writing, but allow
> them to be perhaps ordered and multiple in flight, so that one could use
> that instead of the big-hammer inscrutable writeback cache.
Certainly in the universe of
> On Feb 18, 2021, at 5:43 PM, David Holland wrote:
>
> And currently there's a problem that the only way to flush the
> underlying hardware-level caches is to call fsync_range and pass
> FDISKSYNC. This might be POSIX (is it? man page doesn't say so) but it
> doesn't necessarily seem helpful
> On Jan 26, 2021, at 8:54 PM, Kengo NAKAHARA wrote:
>
> Ah, the stats are just incremented (not atomic ops) because they are
> incremented by one CPU or protected by locks. I will enable it as you
> say.
My thinking is:
1. Probably not much interest on non-LP64 systems.
-and-
2. On
> On Jan 26, 2021, at 7:51 PM, Kengo NAKAHARA wrote:
>
> Hi,
>
> Thank you for your comments.
>
> On 2021/01/27 12:14, Jason Thorpe wrote:
>>> On Jan 26, 2021, at 6:21 PM, Kengo NAKAHARA wrote:
>>>
>>> Someone may worry about
> On Jan 26, 2021, at 6:21 PM, Kengo NAKAHARA wrote:
>
> Someone may worry about any other effects, I will add new kernel option
> WM_DISABLE_EVENT_COUNTERS, please use it.
No strong objection from me, but can we enable it by default only on systems
with 64-bit atomics?
-- thorpej
> On Nov 11, 2020, at 5:38 AM, Martin Husemann wrote:
>
> Yes, and of course the real code has that (and works). It's just that
> - memoryallocators(9) does not cover this case
> - kmem_intr_alloc(9) is kinda deprecated - quoting the man page:
>
> These routines are for the special
> On Nov 11, 2020, at 1:44 AM, Martin Husemann wrote:
>
> In a perfect world we would avoid the interrupt allocation all together, but
> I have not found a way to rearrange things here to make this feasible.
>
> Is kmem_intr_alloc(9) the best way forward?
While softints are backed by threads
> On Nov 10, 2020, at 9:36 AM, Martin Husemann wrote:
>
> The current state of Linux emulation is greatly affected by
> incompatibilities in the futex emulation, so completition/merging
> of the thorpej-futex branch may be a prerequisite for some of the
> projects explained below.
Let me
> On Oct 26, 2020, at 8:58 AM, Julian Coleman wrote:
>
> Hi,
>
> Thanks for the comments!
>
>>> #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
> On Oct 21, 2020, at 11:21 AM, m...@netbsd.org wrote:
>
> On Wed, Oct 21, 2020 at 05:49:38PM +0100, Robert Swindells wrote:
>>
>> Is there any way we can make progress with getting futexes to work
>> properly ?
>>
>> At least post the latest non-working source somewhere so that people can
> On Aug 25, 2020, at 6:41 AM, Robert Swindells wrote:
>
>> The fix is non-trivial, and requires a fundamental change to how futexes
>> work.
>
> That seemed clear in the bug, I guessed it would mean switching to using
> a futex_syncobj (or similar).
Yes, and using sleepq directly.
> I'm
> On Aug 22, 2020, at 11:35 AM, Jason A. Donenfeld wrote:
>
> it needs to be done right,
Can you be specific about what is wrong?
-- thorpej
> On Aug 16, 2020, at 5:58 AM, Robert Swindells wrote:
>
>
> Taylor R Campbell wrote:
>>> Date: Sat, 15 Aug 2020 19:59:24 +0100
>>> From: Robert Swindells
>>>
>>> Is anyone working on the proposed solution to kern/55230 ?
>>
>> thorpej was working on it and has a patch -- I thought it got
From my reading of the code, it seems that there are no longer any
circumstances where pmap_activate() will be called with non-curlwp, at least in
MI code.
Is this a correct reading?
-- thorpej
> On Jul 26, 2020, at 4:20 PM, m...@netbsd.org wrote:
>
> It looks like this difference is because FFS doesn't flush the disk
> cache often, but if WAPBL is enabled, it does on every log write.
Do you mean by issuing a SYNCHRONIZE_CACHE or similar command? Be aware that
there are a lot of
> On Jun 20, 2020, at 8:05 PM, Taylor R Campbell wrote:
>
> I'm open to other naming suggestions but I'm deliberately keeping the
> scope narrow and grounded by specific needs.
mcop? (Math CO-Processor ... certainly, math is a common theme.)
-- thorpej
> On Jun 20, 2020, at 6:52 PM, Erik Fair wrote:
>
> Has anyone using NetBSD played with FPGAs embedded with a processor? I know
> that Intel was talking about adding some to its processors after they bought
> Altera in 2015. There is explicit provision for FPGAs in OpenCL, alongside
> GPUs:
> On Jun 15, 2020, at 12:15 PM, Reinoud Zandijk wrote:
>
> Trying to build LLVM or gcc from pkgsrc? That'll need NetBSD specific patches
> anyway and they can be created on package creation/update by the developer who
> has the source tree anyway or do you want the packages to create a bunch
> On Jun 15, 2020, at 5:49 AM, Mouse wrote:
>
> I considered suggesting something like /usr/tools, but I don't really
> think that's a good idea.
I think it's reasonable to draw a distinction between "tools that are commonly
used for non-system development" and "tools that are very specific
> On Jun 15, 2020, at 6:39 AM, Kamil Rytarowski wrote:
>
> However if we install the utility into /usr/sys (similar to /usr/games),
> we can use a full path to the program and it will be good enough (for
> me). Are there other programs that would be moved to this directory?
The Device Tree
> On May 30, 2020, at 7:18 AM, Christos Zoulas wrote:
>
> 3352 80b940bb:procfs_domounts+0xd
> 3264 80c677da:coredump_note_elf64+0xb
These two seem slightly bogus. coredump_note_elf64() was storing register
state not the stack, but not nearly 3K worth. procfs_domounts() has
> On May 4, 2020, at 2:07 PM, Michael wrote:
>
> I think disabling access to whatever the BAR maps while fudging with it
> is a pretty good idea on its own. Who knows what else lives in that
> area.
Agreed.
-- thorpej
> On Apr 4, 2020, at 2:14 PM, Andrew Doran wrote:
>
> Any comments?
+static int
+fstrans_lwp_ctor(void *arg, void *obj, int flags)
+{
+ struct fstrans_lwp_info *fli = obj;
+
+ memset(fli, 0, sizeof(*fli));
+ membar_sync();
+ mutex_enter(_lock);
+
Can someone please explain to me what the point of DVF_DETACH_SHUTDOWN is? It
seems incredibly misguided.
-- thorpej
> On Feb 24, 2020, at 4:08 PM, Kamil Rytarowski wrote:
>
> NULL in C is expected to be harmonized with nullptr from C++.
This is insanity. C++ is a cesspit where dreams of elegant code go to die.
-- thorpej
...proud owner of a "C++ Barf Bag" that hangs outside his office...
> On Feb 24, 2020, at 4:22 AM, Kamil Rytarowski wrote:
>
> A compiler once being smart enough can introduce ILL/SEGV traps into
> code that performs operations on NULL pointers. This already bitten us
> when we were registering a handler at address 0x0 for the kernel code,
> GCC changed the
> On Jan 29, 2020, at 6:49 PM, Taylor R Campbell
> wrote:
>
>> Date: Thu, 30 Jan 2020 02:46:42 +
>> From: Taylor R Campbell
>>
>> The attached patch set [...]
>
> Some day, perhaps I will not be bad at attachments. That day,
> however, has yet to come.
>
/* low-level api; don't
> On Jan 29, 2020, at 7:18 AM, Taylor R Campbell
> wrote:
>
> I don't think so, because it's OK for the percpu_foreach callback to
> mutex_enter/exit on an adaptive lock even though that might sleep.
> What's not OK is sleeping for allocation or other long durations.
> Merely holding
> On Jan 28, 2020, at 9:46 PM, Taylor R Campbell
> wrote:
>
>> Date: Tue, 28 Jan 2020 20:49:50 -0800
>> From: Jason Thorpe
>>
>> What happens if:
>>
>> oink = percpu_getref(...);
>> ...
>> mutex_enter(
> On Jan 28, 2020, at 8:37 PM, Taylor R Campbell
> wrote:
>
> The reason percpu_foreach takes percpu_swap_lock is so that the
> pointer percpu_getptr_remote returns remains stable _without_
> percpu_getref/putref.
What happens if:
oink = percpu_getref(...);
...
> On Jan 28, 2020, at 7:11 PM, Taylor R Campbell
> wrote:
>
>> Date: Tue, 28 Jan 2020 18:54:59 -0800
>> From: Jason Thorpe
>>
>> Something like this. I haven't tested this yet, but I will shortly.
>> Only high-pri xcalls are supported in this -- to
> On Jan 28, 2020, at 9:20 AM, Taylor R Campbell
> wrote:
>
> OK, that sounds reasonable. (I misunderstood your first message to
> mean that percpu_foreach_xcall would synchronize with _other activity_
> on each CPU, rather than that it would serialize the xcall with itself
> on different
> On Jan 28, 2020, at 9:01 AM, Taylor R Campbell
> wrote:
>
> I see percpu_foreach as being primarily aimed at initialization and
> finalization, for which it is entirely reasonable -- and, at boot
> time, perhaps necessary -- to run on the current CPU.
Sure, but that's not the way it's used
> On Jan 28, 2020, at 8:40 AM, Taylor R Campbell
> wrote:
>
> Why not just use xc_broadcast? Does a cross-calling version of
> percpu_foreach really help simplify much or clarify anything?
I suppose I could, but:
1- This seems to be a general issue with percpu_foreach(). I mean, one of
So, percpu_foreach() is pretty handy for enumerating data that's managed on a
per-cpu basis. But there's a problem ... it does not actually execute the
callback on the remote CPU, instead getting a pointer to the remote data and
accessing it directly.
Does this seem like a problem to anyone
(Cross-posted to tech-kern / tech-net because it affects networking and file
systems.)
I would like to propose that we remove netsmb and smbfs. Two reasons:
1- They only support SMB1, which is an ancient flavor of the protocol. SMB2
was introduced in 2006 and SMB3 in 2012. SMB3 is the
Hey folks --
Back in the early 2000s, I wrote the "dmover" API, which provided a facility
for data-mover engines to provide a common interface. It supports basic data
movement and XOR.
Unfortunately, it never really took off. A few SoC back-ends exist... For the
Intel i80321 Application
> On Jan 14, 2020, at 2:37 PM, Christos Zoulas wrote:
>
> So what's the short term solution?
>
> - Don't define {MIN,MAX}_PAGE_SIZE on m68k?
> - Define a different constant?
> - Add a define to tell uvm to ignore {MIN,MAX}_PAGE_SIZE?
#ifdef _KERNEL, define {MIN,MAX}_PAGE_SIZE to a constant
> On Jan 14, 2020, at 10:16 AM, Christos Zoulas wrote:
>
> We do this to save space, but as you say, not important for now. Perhaps
> the expedient solution is to define MALLOC_PAGE_SIZE...
I'd rather keep the use of these constants separate... who knows what they
might be used for in the
> On Jan 14, 2020, at 8:41 AM, Izumi Tsutsui wrote:
>
>> b) Modules should be built such that they can use a non-fixed PAGE_SIZE.
>
> No, this is not necessary, because modules are built for each $MACHINE
> and (a) each $MACHINE has fixed PAGE_SIZE.
Yes, understood. I think it would
> On Jan 13, 2020, at 10:24 AM, Christos Zoulas wrote:
>
> Talking to myself:
>
> The arm PAGE_SIZE_{MIN,MAX} should go away after nick eliminates the
> need for the 8K pages. This leaves us with m68k to deal with...
> Do modules work on m68k? Should modules be shared between kernels with
>
> On Jan 2, 2020, at 10:16 AM, co...@sdf.org wrote:
>
> Hi folks,
>
> urio(4) is a driver for Rio 500, an MP3 player released in 1999.
> It recently received some discussion due to problems detected
> during maxv's USB-fuzzing.
Yah, seems like a good candidate for nuking.
>
> Since I expect
> On Dec 24, 2019, at 1:17 PM, Andrew Doran wrote:
>
> Looks like it wouldn't be too hard to wrap this in a function to return it
> and at least keep the problem in one place. Ah ha! When searching for
> boottime on OpenGrok I found a FreeBSDism in the NFS code that we pulled in:
>
As you may have noticed, I've been doing a significant amount of tidying up in
the i2c code, specifically getting rid of polled mode access as much as
possible, and auditing everything for "accesses i2c in hard interrupt context"
(which is not safe). I am mostly complete with this task, but
> On Dec 19, 2019, at 9:46 AM, Christos Zoulas wrote:
>
> LGTM, thanks for doing this.
I've pushed this in. I'll watch for any fallout over the coming days.
-- thorpej
The i2c subsystem has a mechanism by which drivers for i2c-connected devices
"acquire" and "release" the i2c bus for their own exclusive access while
performing a set of operations. Historically, it has been the responsibility
of the back-end controller drivers to implement this mechanism,
> On Dec 8, 2019, at 6:00 AM, Mindaugas Rasiukevicius wrote:
>
> Just a small note: since vm_page::wire_count and vm_page::loan_count are
> kind of mutually exclusive, I think suggestion by yamt@ (long time ago) to
> merge them (positive value meaning wired count and negative -- loan) is a
>
> On Dec 6, 2019, at 11:44 AM, paul.kon...@dell.com wrote:
>
> For clean semantics, I like ALGOL; too bad it is no longer used
There's just too much shouting in ALGOL.
-- thorpej
> On Dec 4, 2019, at 8:47 AM, Kamil Rytarowski wrote:
>
> Today it's missing.. do we need it in core files?
Seems like you would absolutely need it in core files, otherwise the debugger
won't know what it is when performing a post-mortem.
If we add a ptrace accessor a'la Linux, then it
There are plenty of “always 1” bits in the kernel VAs... we steal some of those
to represent flags and just OR them back in when the bus space accesses are
done.
-- thorpej
Sent from my iPhone.
> On Dec 2, 2019, at 11:30 AM, Andrew Doran wrote:
>
> On Mon, Dec 02, 2019 at 07:03:50PM +,
> On Dec 2, 2019, at 11:03 AM, Andrew Doran wrote:
>
> I think the way to avoid both of those would be key off the bus_space_tag_t.
> There are already two, one for I/O and one for memory. We could do multiple
> memory tags. That's probably very easy, I think the harder bit would likely
>
> On Nov 18, 2019, at 3:32 PM, Mouse wrote:
>
> You could do that. Creating a large hole would cost you the time to
> allocate and initialize the indirect blocks, but I suppose that's a
> factor of the block size smaller than the time it would take to
> allocate and initialize all the data
> On Nov 18, 2019, at 1:13 PM, Mouse wrote:
>
>> Now, what happens if you do a posix_fallocate("foo", 0, 4GiB)? The file sys$
>
> Given the intent of posix_fallocate as I understand it, that's the only
> reasonable option for FFS. If a filesystem has a way to record a block
> that should
of what might have been in that now-allocated space on disk before,
which can be a security risk.
>
> Regards,
> Hrishikesh
>
> On Mon, Nov 18, 2019, 23:34 Jason Thorpe wrote:
>
>
> > On Nov 17, 2019, at 11:21 AM, HRISHIKESH GOYAL
> > wrote:
> >
> &g
> On Nov 17, 2019, at 11:21 AM, HRISHIKESH GOYAL wrote:
>
> Questions:
> 1. As what I follow from the above stackoverflow answer and truncate man
> page, even though `truncate` doesn't allocate space for file baz but
> filesystem should still update the free space by reducing it to
>
> On Nov 6, 2019, at 5:41 AM, Kamil Rytarowski wrote:
>
> On 06.11.2019 14:37, Jason Thorpe wrote:
>>
>>
>>> On Nov 6, 2019, at 4:45 AM, Kamil Rytarowski wrote:
>>>
>>> I propose __write_relaxed() / __read_relaxed().
>>
>>
> On Nov 6, 2019, at 4:45 AM, Kamil Rytarowski wrote:
>
> I propose __write_relaxed() / __read_relaxed().
...except that seems to imply the opposite of what these do.
-- thorpej
> On Nov 3, 2019, at 4:06 AM, Jared D. McNeill wrote:
>
> Module Name: src
> Committed By: jmcneill
> Date: Sun Nov 3 12:06:33 UTC 2019
>
> Modified Files:
> src/sys/arch/arm/fdt: smsh_fdt.c
>
> Log Message:
> Match smsc,lan9115 and honour local-mac-address/mac-address
101 - 200 of 408 matches
Mail list logo
