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
pecification that resembles the syscalls.master for ioctls?
> Shouldn't there be one?
There is not and there should be, that's part of the goal.
> Reading the discussion, I got the idea that the preferred place to
> store the definitions for userland usage is internally in the
> compile
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 prob
> 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
non-C languages
when compiling the languages from pkgsrc. I presume creating 'C' like stubs or
data structures for them to parse and create code with?
Reading the discussion, I got the idea that the preferred place to store the
definitions for userland usage is internally in the compiled makesyscalls;
, but this is serious feature creep going on! You want at
compilation time (of those languages) to auto generate the equivalent header
and system call stubs using the data? See below.
> For a developer it is fine to request BSDSRCDIR to be available, but for
> users (of e.g. GDB) this is certainly
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
d userland
versions.
Something we possibly agree upon is that makesyscalls(1) would not be a
tool for administer a computer/server, so /usr/sbin /sbin is not a good
place.
I agree that /sbin also does not feel natural for makesyscalls. If I
were to have to choose between /bin or /sbin, I would
> 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
where. fsdb(8) or crash(8) are
definitely not going to be very usable with mixed kernel and userland
versions.
Something we possibly agree upon is that makesyscalls(1) would not be a
tool for administer a computer/server, so /usr/sbin /sbin is not a good
place.
signature.asc
Description: OpenPGP d
resentative of "users".
>>
>
>NetBSD is a my daily driver so I'm a user!
>
>> But it would be interesting to hear how and when you are planning to
>use
>> makesyscalls.
>>
>
>I work with the syscall layer almost continuously in various projects
&
han the developer's computer.
>>
>> I personally think that the definition file shall be embedded directly into
>> the program to avoid any issues with incompatible script version vs
>> makesyscalls(1) program.
>
> You got a point there, and embedding it woul
>> 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,
definition file shall be embedded directly into
> the program to avoid any issues with incompatible script version vs
> makesyscalls(1) program.
You got a point there, and embedding it would make sense yes; but i still
wouldn't install the program or its definition files as its kernel source
version d
rly representative of "users".
>
NetBSD is a my daily driver so I'm a user!
> But it would be interesting to hear how and when you are planning to use
> makesyscalls.
>
I work with the syscall layer almost continuously in various projects
(debuggers, fuzzers, syscall tracers, s
it we really want it on
> the $PATH, so...
I agree with that logic, that makesyscalls is kind of like config, and
that /usr/bin makes sense. There's nothing admin-ish about it, as
building an operating system is not about configuring the host.
We could have a directory for tools used only for
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
definitely would use makesyscall(1). If you have other argument that
"I don't use it" please speak up.
I'm not convinced you are particularly representative of "users".
But it would be interesting to hear how and when you are planning to use
makesyscalls.
Johnny
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
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 software and this
is just another specialized program similar to flex(1) or yacc(1), just
a more domain specific code generator.
Is ping only for people with root
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
an the developer's computer.
I personally think that the definition file shall be embedded directly
into the program to avoid any issues with incompatible script version vs
makesyscalls(1) program.
signature.asc
Description: OpenPGP digital signature
ded:
>
> (1) What's the new tool called, and where does it live in the tree?
> "usr.bin/makesyscalls" is fine with me but ymmv.
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
cre
or users with root
>> privileges, while /bin and /usr/bin for everybody. makesyscalls(1)
>> intends to be an end-user program that aids building software and this
>> is just another specialized program similar to flex(1) or yacc(1), just
>> a more domain specific co
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 f
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 intereste
in the tree?
"usr.bin/makesyscalls" is fine with me but ymmv.
"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 makesyscalls
;usr.bin/makesyscalls" is fine with me but ymmv.
"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 makesyscalls would be a tool l
> 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
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 bu
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 i
lled, and where does it live in the tree?
>>> "usr.bin/makesyscalls" is fine with me but ymmv.
>>
>> "usr.bin/makesyscalls" sounds good to me.
>
> Uh? usr.bin is where stuff for /usr/bin is located, right? Anything
> there should be pretty no
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/makesyscal
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 t
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.
It seems to me that all of the following is mechanical and should be
automatically generated, beyond what makesyscalls already does
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:
>
Between various forms of prompting I got tired of waiting for a gsoc
student to take up code generation for syscall argument handling. We
should really be generating all the calls to copyin/copyout, not to
mention all the compat32 and compat_* glue, not maintaining them by
hand. More on that
50 matches
Mail list logo
