> On Feb 25, 2024, at 12:29 AM, Robert Elz wrote:
>
> ps: as a semi-related anecdote, the first system I ever personally
> installed any unix version onto (way back in the mid 70's) booted from
> a reel to reel (1/2" I think) tape - and by booted, I mean ran with its
> filesystems (or
(This should really be on tech-kern…)
> On Feb 21, 2024, at 1:20 PM, Taylor R Campbell
> wrote:
>
>> Date: Wed, 21 Feb 2024 10:52:55 +
>> From: Sad Clouds
>>
>> Hello, for most operating systems determining the size of a block
>> device can be done with:
>>
>> lseek(fd, 0, SEEK_END);
>>
> On Feb 21, 2024, at 2:52 AM, Sad Clouds wrote:
>
> Hello, for most operating systems determining the size of a block
> device can be done with:
>
> lseek(fd, 0, SEEK_END);
On what operating systems does this do what you claim?
> However, on NetBSD this does not seem to work.
It doesn’t
> On Aug 26, 2023, at 1:59 AM, Taylor R Campbell wrote:
>
> Module Name: src
> Committed By: riastradh
> Date: Sat Aug 26 05:59:00 UTC 2023
>
> Modified Files:
> src/usr.sbin/postinstall: postinstall.in
>
> Log Message:
> postinstall(8): Add opensslcerts item to regen /etc/openssl/certs.
>
> On Jul 31, 2023, at 6:53 PM, Theodore Preduta wrote:
>>
>> epoll(2) for COMPAT_LINUX is implemented in as similar manner to
>> NetBSD's. Therefore, it should also have this compatible issue.
>
> The epoll implementation is literally a direct port of the one from
> FreeBSD's Linux
> On Jul 31, 2023, at 6:25 PM, Rin Okuyama wrote:
>
> epoll(2) for COMPAT_LINUX is implemented in as similar manner to
> NetBSD's. Therefore, it should also have this compatible issue.
> Is is still useful for real Linux applications? Or do you have a
> plan to lift this limitation?
When I
> On Jul 31, 2023, at 1:38 AM, nia wrote:
>
> Hey, I regret that epoll was committed without further discussion with
> pkgsrc developers. We have a lot of experience with this already
> (illumos/SmartOS exposes a compatibility epoll) and the situation is
> not entirely great and requires lots
> On Jul 1, 2023, at 6:20 PM, Emmanuel Dreyfus wrote:
>
> On Sat, Jul 01, 2023 at 02:25:03PM +, RVP wrote:
>> Not to forget the code for C++ support. And, of course even static
>> binaries may call dlopen() and friends. So that dl*() and the ELF bits
>> right there.
>
> At least in 9.3,
> On Jul 1, 2023, at 1:41 PM, Michael van Elst wrote:
>
> thor...@me.com (Jason Thorpe) writes:
>
>> Obviously this is not feasible to do with static binaries
>
> In the world of go, you skip libc and static binaries are the norm.
Go sounds poorly designed, then.
-- thorpej
> On Jul 1, 2023, at 8:20 AM, tlaro...@polynum.com wrote:
>
> This is also what I meant by "static seems to be considered deprecated".
Honestly, I find the obsession with static linking hilariously quaint. NetBSD
already bends backwards to an extreme degree by ensuring that old version of
> On Jul 1, 2023, at 8:51 AM, Mouse wrote:
>
> Why TLS?? Is there some networking going on under the hood?
Thread Local Storage
-- thorpej
> On Jun 30, 2023, at 11:30 PM, tlaro...@polynum.com wrote:
>
> Le Fri, Jun 30, 2023 at 01:37:10PM -0400, Mouse a écrit :
>> Based on something at work, I was looking at executable sizes. I
>> eventually tried a program stripped about as far down as I could:
>>
>> int main(void);
>> int
> On May 17, 2023, at 11:47 AM, tlaro...@polynum.com wrote:
>
> But the fact that the advertised list of changes for 10 stops at
> February 2023 is probably something the webmaster(s) should look
> at: it's a bit confusing/disturbing...
Those are just the major changes. There has been a focus
> On May 17, 2023, at 11:21 AM, tlaro...@polynum.com wrote:
>
> I don't know on what mailing list to ask this...
>
> I have seen on the web site that changes to 10 have stopped in february
> and that changes are now for 11...
>
> Does this mean that 10 will never be released and that the
> On Mar 28, 2023, at 5:53 PM, Roland Illig wrote:
>
> Am 15.03.2023 um 16:40 schrieb Jason Thorpe:
>>
>>> On Mar 15, 2023, at 4:23 AM, Taylor R Campbell
>>> wrote:
>>>
>>> Proposal: Forbid extern declarations in .c files.
>>>
> On Mar 15, 2023, at 4:23 AM, Taylor R Campbell
> wrote:
>
> Proposal: Forbid extern declarations in .c files.
>
> extern declarations in .c files invite easily avoided bugs where the
> definition and use have mismatched types, because the compiler doesn't
> have an opportunity to check
> On Jan 5, 2023, at 8:53 AM, Christos Zoulas wrote:
>
> Hello,
>
> Our dynamic linker ld_elf.so in map_object.c currently can only handle 2
> PT_LOAD segments (one for text and one for data); the kernel elf loader does
> not have this limitation, it can load multiple PT_LOAD segment. The
See responses further down in-line:
> On Aug 20, 2022, at 8:51 AM, Emmanuel Dreyfus wrote:
>
> Hello
>
> I have a ihidev device that fails to find its HID descriptor. In order to
> debug that, I try to retreive it from userspace.
>
> At kernel boot, I have:
> ihidev1 at iic2 addr 0x5d
>
> I
> On Jul 5, 2022, at 8:28 PM, Brook Milligan wrote:
>
> Installboot can install U-Boot boot blocks directly into a system image.
> Normally, the U-Boot files are searched for in /usr/pkg/share/u-boot, under
> the expectation that most people will build them with pkgsrc. However, it is
>
> On Apr 9, 2022, at 8:49 AM, Robert Elz wrote:
> Just stop suggesting removing things for no better reason than
> that you see no point keeping them. If the existence of something
> which seems not to be all that necessary is being a roadblock
> to getting other work done, then by all means,
> On Feb 15, 2022, at 5:13 PM, Mouse wrote:
>
>> There really should be a function that takes a user name or ID and a clearte$
>
> Maybe. But then you have a lot more failure modes and a lot more
> possible attack surface. It would also mean that you can't check or
> change passwords in
> On Feb 15, 2022, at 3:30 PM, Joerg Sonnenberger wrote:
>
> Am Wed, Feb 16, 2022 at 12:04:16AM +0100 schrieb Niclas Rosenvik:
>> do you mean that the interface should be
>> crypt_r(const char *key, const char setting, char * storage, size_t
>> *storage_len)
>> where storage can be set to
> On Oct 26, 2021, at 11:07 AM, Robert Elz wrote:
>
>Date:Tue, 26 Oct 2021 18:27:20 +0300
>From:Valery Ushakov
>Message-ID:
>
> | OTOH the old
> | *binaries* (using old dynamic libc, or linked with old static libc)
> | still need the kernel support.
>
> I
> On Oct 26, 2021, at 8:27 AM, Valery Ushakov wrote:
>
> I'm not sure why we left the sigcontext version in the tree. I would
> guess for reference only, so it doesn't really need any fixing, as far
> as I understand.
Presumably it was to keep old binaries that used the sigcontext style
> On Oct 26, 2021, at 6:56 AM, Jason Thorpe wrote:
>
> Obviously, the practical impact of this is nil, since no one apparently
> noticed (and I guess we didn’t break any programs that people were using). We
> haven’t documented that style of handler for a VERY long time
Hey folks —
I was looking into the request for a libc function that determined if a program
counter was inside a signal trampoline (see
https://mail-index.netbsd.org/tech-kern/2021/10/15/msg027703.html), and the
first thing I decided to do as part of this was unify all of the
> On Sep 28, 2021, at 7:35 AM, Izumi Tsutsui wrote:
>
> FYI,
> https://mail-index.netbsd.org/netbsd-bugs/2018/09/24/msg059139.html
I guess old habits die hard :-)
Ok, well, then I won’t ask if it should be G/C’d :-)
-- thorpej
Anyone?
-- thorpej
[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 Jun 3, 2021, at 7:19 AM, Emmanuel Dreyfus wrote:
>
> Is there any reason not to fix it?
Seems like it would be a bad idea NOT to fix it. I assume one of the goals of
librefuse was to be ABI compatible?
-- thorpej
> On May 21, 2021, at 5:06 PM, David Holland wrote:
>
> The workings of the various *mcount functions are confusing and
> currently undocumented. After wading into it just now for I think the
> third time recently, I wrote the following to ease the process.
This looks awesome, David, thanks
> On May 6, 2021, at 6:44 AM, nia wrote:
>
> I think this version is suitable for importing into NetBSD base
> for continued development. This will also allow us to easily
> keep it in sync if there are any changes to the audio stack.
This is really cool, I would support this!
-- thorpej
> On Apr 8, 2021, at 11:15 AM, Mouse wrote:
>
> I'm curious: why do you care? If, of course, it's anything you can
> talk about.
I have a set of futex-based synchronization objects for libpthread I’ve been
hacking on off-and-on for a while.
-- thorpej
> On Apr 8, 2021, at 11:15 AM, Mouse wrote:
>
>> Is there ANY situation where, for a given pthread condition variable, that u$
>
> For what value of "legitimate"?
>
> I see no reason why this would/should be forbidden, and, indeed, at
> least the 5.2 manpage for pthread_cond_wait seems to
As far as I can tell, POSIX has no language that covers this situation, so I’m
tossing it out here for the hive mind...
Is there ANY situation where, for a given pthread condition variable, that
using a different mutex as the interlock in two different calls to
pthread_cond_wait() would EVER
> On Mar 30, 2021, at 8:03 PM, Christos Zoulas wrote:
>
> There are 3 x 'sizeof(' in the tree compared to 'sizeof ' in '*.c' and
> I am counting 'sizeof (' as 'sizeof ':
>
> 191337 'sizeof('
> 63508 'sizeof '
>
> I think that it is better to bless the prevailing majority as the rule,
> but
> On Mar 16, 2021, at 4:55 PM, Roland Illig wrote:
>
> Any objections to removing the -t flag and everything that belongs to it?
No objections from me.
-- thorpej
> On Mar 12, 2019, at 9:09 PM, Robert Elz wrote:
>
> The first issue I noticed, is that t_mlock() apparently belives
> the malloc(3) man page, which states:
>
> The malloc() function allocates size bytes of uninitialized memory. The
> allocated space is suitably aligned (after
> 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
> 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 poin
> 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
41 matches
Mail list logo
