On Mon, Jun 15, 2020 at 10:56:04PM +, David Holland wrote:
> A less glib example: line 3186 of vfs_syscalls.c, in stat or more
> precisely sys___stat50, has a handwritten call to copyout() to
> transfer the stat results back to userspace.
OK, this could be improved if we had the IOR/IOW/IORW
On Tue, Jun 16, 2020 at 12:21:33AM +0100, Roy Marples wrote:
> On 16/06/2020 00:07, David Holland wrote:
> > Kamil thinks that. I don't see why. Compiling data into tools just
> > complicates everything.
>
> libterminfo.so has some terms compiled into it if the databases are
> unreadable
On Mon, Jun 15, 2020 at 10:56:04PM +, David Holland wrote:
> A less glib example: line 3186 of vfs_syscalls.c, in stat or more
> precisely sys___stat50, has a handwritten call to copyout() to
> transfer the stat results back to userspace.
To amplify:
Currently syscalls.master says:
439
On 16/06/2020 00:07, David Holland wrote:
Kamil thinks that. I don't see why. Compiling data into tools just
complicates everything.
libterminfo.so has some terms compiled into it if the databases are unreadable
for any reason. A handy fallback.
dhcpcd also embedds dhcpcd.conf definitions
On Mon, Jun 15, 2020 at 10:15:09PM +0200, Reinoud Zandijk wrote:
> It would be great if that can be done for the ioctls dispatch code
> as well and cover their copyin/copyout stuff, its now all over the
> place; I think that would save a lot of hidden bugs. Is there a
> specification that
On Mon, Jun 15, 2020 at 09:19:19AM +0200, Martin Husemann wrote:
> > It seems to me that all of the following is mechanical and should be
> > automatically generated, beyond what makesyscalls already does:
> >- all the code that calls copyin/copyout
>
> It is probably too early and I had
> 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 Mon, Jun 15, 2020 at 05:16:01PM -, Christos Zoulas wrote:
> In article <20200615120806.gb1...@diablo.13thmonkey.org>, Reinoud Zandijk
> wrote:
> >LLVM code and its fuzzing tools should be in tree anyway so it can be
> >created there on the fly too if requested.
>
> How about strace, or
On Mon, Jun 15, 2020 at 02:58:31PM +0200, Kamil Rytarowski wrote:
> LLVM is an external project and only in a special case part of the
> basesystem. While there, there is the same issue with GCC sanitizers. We
> definitely don't want to request regular LLVM or GCC users building the
> toolchain to
In article <20200615120806.gb1...@diablo.13thmonkey.org>,
Reinoud Zandijk wrote:
>Small addendum,
>
>On Mon, Jun 15, 2020 at 01:44:19PM +0200, Reinoud Zandijk wrote:
>> What about not installing it at all? Its only going to be used during
>> definition updates or fixes. Compare it to the
> 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 2020-06-15 15:39, Kamil Rytarowski wrote:
On 15.06.2020 15:21, Johnny Billquist wrote:
Anyway. Who here does not modify their path at login anyway.
The path has to be readily available for pkgsrc users with unprepared
environment.
However if we install the utility into /usr/sys (similar
> 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 15.06.2020 15:21, Johnny Billquist wrote:
>
> Anyway. Who here does not modify their path at login anyway.
The path has to be readily available for pkgsrc users with unprepared
environment.
However if we install the utility into /usr/sys (similar to /usr/games),
we can use a full path to the
Sorry for the top posting terse reply. On my phone as I'm in a meeting at work
right now.
Anyway. Who here does not modify their path at login anyway. So arguments like
"I need it in bin because I am going to use it a lot" seems like weak
arguments. Think of what make sense for people that
On 15.06.2020 14:35, Reinoud Zandijk wrote:
> On Mon, Jun 15, 2020 at 02:06:00PM +0200, Kamil Rytarowski wrote:
>> On 15.06.2020 13:44, Reinoud Zandijk wrote:
>>> No need to install it in base. The resulting files can then be committed
>>> as `regen' just like the pcidevs variants.
>>
>> I
>> We should not clutter the directories that are in the normal users
>> path with things that a normal user would never care about.
> I never used 90% of the programs from /usr/bin /usr/sbin /bin /sbin.
Me neither. calendar, indxbib, texi2dvi, newsyslog, lastcomm, sdiff,
innetgr...actually,
On Mon, Jun 15, 2020 at 02:06:00PM +0200, Kamil Rytarowski wrote:
> On 15.06.2020 13:44, Reinoud Zandijk wrote:
> > No need to install it in base. The resulting files can then be committed
> > as `regen' just like the pcidevs variants.
>
> I disagree as we don't want to pull ${BSDSRCDIR}
On 15.06.2020 14:16, Johnny Billquist wrote:
> On 2020-06-15 14:12, Kamil Rytarowski wrote:
>> On 15.06.2020 14:11, Johnny Billquist wrote:
>>>
>>> We should not clutter the directories that are in the normal users path
>>> with things that a normal user would never care about.
>>
>> I never used
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
On 2020-06-15 14:16, Johnny Billquist wrote:
On 2020-06-15 14:12, Kamil Rytarowski wrote:
On 15.06.2020 14:11, Johnny Billquist wrote:
We should not clutter the directories that are in the normal users path
with things that a normal user would never care about.
I never used 90% of the
On 2020-06-15 14:12, Kamil Rytarowski wrote:
On 15.06.2020 14:11, Johnny Billquist wrote:
We should not clutter the directories that are in the normal users path
with things that a normal user would never care about.
I never used 90% of the programs from /usr/bin /usr/sbin /bin /sbin. but
I
On 2020-06-15 14:08, Reinoud Zandijk wrote:
On Mon, Jun 15, 2020 at 01:44:19PM +0200, Reinoud Zandijk wrote:
As for config(1), I never understood why it is installed in /usr/bin and is
called with such a generic name, but i guess thats historical.
It's not that historical. And I really think
On 15.06.2020 14:11, Johnny Billquist wrote:
>
> We should not clutter the directories that are in the normal users path
> with things that a normal user would never care about.
I never used 90% of the programs from /usr/bin /usr/sbin /bin /sbin. but
I definitely would use makesyscall(1). If you
On 2020-06-15 12:25, Kamil Rytarowski wrote:
On 15.06.2020 00:57, Johnny Billquist wrote:
On 2020-06-15 00:52, Kamil Rytarowski wrote:
On 15.06.2020 00:26, Johnny Billquist wrote:
But that's just me. I'll leave the deciding to you guys...
This is only me, but /sbin and /usr/sbin are for
Small addendum,
On Mon, Jun 15, 2020 at 01:44:19PM +0200, Reinoud Zandijk wrote:
> What about not installing it at all? Its only going to be used during
> definition updates or fixes. Compare it to the pcidevs.h and pcidevs_data.h
> creation only this time it creates the relevant
On 15.06.2020 13:44, Reinoud Zandijk wrote:
> No need to install it in base. The resulting
> files can then be committed as `regen' just like the pcidevs variants.
I disagree as we don't want to pull ${BSDSRCDIR} dependency for users,
for building an application.
This utility shall receive ATF
On Sun, Jun 14, 2020 at 09:07:45PM +, David Holland wrote:
> As I mentioned a few days ago the reason I was prodding
> makesyscalls.sh is that I've been looking at generating more of the
> system call argument handling code.
...
> This raises two points that need to be bikeshedded:
>
> (1)
On 15.06.2020 00:57, Johnny Billquist wrote:
> On 2020-06-15 00:52, Kamil Rytarowski wrote:
>> On 15.06.2020 00:26, Johnny Billquist wrote:
>>> But that's just me. I'll leave the deciding to you guys...
>>>
>>
>> This is only me, but /sbin and /usr/sbin are for users with root
>> privileges, while
On Sun, Jun 14, 2020 at 09:07:45PM +, David Holland wrote:
> It seems to me that all of the following is mechanical and should be
> automatically generated, beyond what makesyscalls already does:
>- all the code that calls copyin/copyout
It is probably too early and I had too few coffee -
On Sun, Jun 14, 2020 at 02:21:07PM -0700, Paul Goyette wrote:
> > (2) What is the installed syscall description file called and where
> > does it go? It is likely to be derived from (i.e., not the same as)
> > syscalls.master. It isn't a C header file so it doesn't belong in
> > /usr/include.
On Sun, Jun 14, 2020 at 11:59:54PM +0200, Johnny Billquist wrote:
> > "usr.bin/makesyscalls" sounds good to me.
>
> Uh? usr.bin is where stuff for /usr/bin is located, right? Anything there
> should be pretty normal tools that any user might be interested in. Don't
> seem to me as
On 2020-06-15 00:07, Kamil Rytarowski wrote:
On 14.06.2020 23:59, Johnny Billquist wrote:
On 2020-06-14 23:21, Paul Goyette wrote:
On Sun, 14 Jun 2020, David Holland wrote:
This raises two points that need to be bikeshedded:
(1) What's the new tool called, and where does it live in the
On 2020-06-15 00:50, Robert Swindells wrote>
Johnny Billquist wrote:
On 2020-06-14 23:21, Paul Goyette wrote:
On Sun, 14 Jun 2020, David Holland wrote:
This raises two points that need to be bikeshedded:
(1) What's the new tool called, and where does it live in the tree?
> This is only me, but /sbin and /usr/sbin are for users with root
> privileges, while /bin and /usr/bin for everybody.
Maybe mostly. But there are exceptions enough that I think keeping
this with the likes of config(1) and genassym(1) makes sense,
especially in view of cross-builds.
On 2020-06-15 00:52, Kamil Rytarowski wrote:
On 15.06.2020 00:26, Johnny Billquist wrote:
But that's just me. I'll leave the deciding to you guys...
This is only me, but /sbin and /usr/sbin are for users with root
privileges, while /bin and /usr/bin for everybody. makesyscalls(1)
intends to
On 15.06.2020 00:26, Johnny Billquist wrote:
> But that's just me. I'll leave the deciding to you guys...
>
This is only me, but /sbin and /usr/sbin are for users with root
privileges, while /bin and /usr/bin for everybody. makesyscalls(1)
intends to be an end-user program that aids building
Johnny Billquist wrote:
>On 2020-06-14 23:21, Paul Goyette wrote:
>> On Sun, 14 Jun 2020, David Holland wrote:
>>
>>
>>
>>> This raises two points that need to be bikeshedded:
>>>
>>> (1) What's the new tool called, and where does it live in the tree?
>>> "usr.bin/makesyscalls" is fine with
On 14.06.2020 23:59, Johnny Billquist wrote:
> On 2020-06-14 23:21, Paul Goyette wrote:
>> On Sun, 14 Jun 2020, David Holland wrote:
>>
>>
>>
>>> This raises two points that need to be bikeshedded:
>>>
>>> (1) What's the new tool called, and where does it live in the tree?
>>>
On 2020-06-14 23:21, Paul Goyette wrote:
On Sun, 14 Jun 2020, David Holland wrote:
This raises two points that need to be bikeshedded:
(1) What's the new tool called, and where does it live in the tree?
"usr.bin/makesyscalls" is fine with me but ymmv.
"usr.bin/makesyscalls" sounds good to
On Sun, 14 Jun 2020, David Holland wrote:
This raises two points that need to be bikeshedded:
(1) What's the new tool called, and where does it live in the tree?
"usr.bin/makesyscalls" is fine with me but ymmv.
"usr.bin/makesyscalls" sounds good to me.
(2) What is the installed syscall
On Fri, Jun 12, 2020 at 04:40:28PM +0200, Reinoud Zandijk wrote:
> > Yes, it can be rewritten in C as a subsequent step. *After* quite a
> > bit of tidying. And no, I'm not doing that now. Among other problems,
> > compiling it requires bikeshedding where to put it in the tree. Feel
> > free
On Wed, Jun 10, 2020 at 08:58:57AM +, David Holland wrote:
> On Wed, Jun 10, 2020 at 01:25:03AM -0400, Thor Lancelot Simon wrote:
> > Could you translate your prototype into a
> > different language, one that's less basically hostile to our build system
> > and its goals and benefits?
>
>
On 06/10, David Holland wrote:
> On Wed, Jun 10, 2020 at 01:25:03AM -0400, Thor Lancelot Simon wrote:
> > Could you translate your prototype into a
> > different language, one that's less basically hostile to our build system
> > and its goals and benefits?
>
> Like which one?
How about
On Wed, Jun 10, 2020 at 01:25:03AM -0400, Thor Lancelot Simon wrote:
> Could you translate your prototype into a
> different language, one that's less basically hostile to our build system
> and its goals and benefits?
Like which one? You removed the part of the post that explained that
there
Python is essentially uncrosscompilable and its maintainers have repeatedly
rudely rejected efforts to make it so.
If that weren't the case, and the way installed Python modules were "managed"
(I use the term liberally) were made sane, I'd think it were a fine thing to
use in base. But it is the
i'm not very interested in a solution that doesn't use tools
available to the build. you've not shown that there is
sufficient pain here to force an external solution. i'm not
sure i buy your claims about awk and size of program. IME,
it just requires that one is strict to rules.
if you want
On 10.06.2020 01:13, David Holland wrote:
> The question is: do we want the Python version in the tree now
For this, I would say "NO", at least as long Python is out of base and
IMO it shall not be there.
But it is fine to put into othersrc/.
On 10.06.2020 01:13, David Holland wrote:
>
48 matches
Mail list logo
