Re: Proposed change to makesyscalls.sh

2018-08-08 Thread Paul Goyette
I'm still not totally sure if this change is worthwhile. However, it does resolve the issue in kern/45781, and it removes the need for the work-around as currently implemented in src/sys/arch/usermode/modules/syscallemu/syscallemu.c I really would appreciate feedback from others on

Re: Proposed change to makesyscalls.sh

2018-08-06 Thread Paul Goyette
| My initial pass at this was to maintain the bit vector at run-time | rather than having makesyscalls.sh calculate the value. The cost to | set the bits in syscall_establish() is not very large. EIther way, but that makes the kernel fractionally bigger for no real benefit - if it can be

Re: Proposed change to makesyscalls.sh

2018-08-06 Thread Rhialto
On Mon 06 Aug 2018 at 05:07:03 +0800, Paul Goyette wrote: > Well, as I indicated before, it's not really essential to restore the > original value. If we blindly reset to sys_nomodule the only down-side > is the attempt to find an auto-loadable module on subsequent calls for > the

Re: Proposed change to makesyscalls.sh

2018-08-05 Thread Robert Elz
Date:Mon, 6 Aug 2018 07:06:42 +0800 (+08) From:Paul Goyette Message-ID: | I looked into using bitstring(3) operations, but since that stuff "lives | in" /usr/include/bitstring.h it wasn't clear if using it in kernel code | would be appropriate. Doesn't matter

Re: Proposed change to makesyscalls.sh

2018-08-05 Thread Paul Goyette
On Mon, 6 Aug 2018, Robert Elz wrote: Date:Mon, 6 Aug 2018 05:07:03 +0800 (+08) From:Paul Goyette Message-ID: | Or we could just leave things alone, and tolerate the "hack" that is | currently being used. Or there could just be a new 1 bit/syscall const data

Re: Proposed change to makesyscalls.sh

2018-08-05 Thread Robert Elz
Date:Mon, 6 Aug 2018 05:07:03 +0800 (+08) From:Paul Goyette Message-ID: | Or we could just leave things alone, and tolerate the "hack" that is | currently being used. Or there could just be a new 1 bit/syscall const data struct that says whether the original

Re: Proposed change to makesyscalls.sh

2018-08-05 Thread Martin Husemann
On Sun, Aug 05, 2018 at 09:09:54PM +0800, Paul Goyette wrote: > We could change syscall_establish() to install for both sys_nomodule or > sys_nosys entry points. But then we'd need to remember which value to > restore when syscall_disestablish() is called. Change the API and make

Re: Proposed change to makesyscalls.sh

2018-08-05 Thread Paul Goyette
On Sun, 5 Aug 2018, Martin Husemann wrote: On Sun, Aug 05, 2018 at 06:24:25AM +0800, Paul Goyette wrote: The primary usage for this is for arch/usermode's syscallemu() which (according to those working on arch/usermode) could be considered "dangerous" and "should never be autoloaded. Having

Re: Proposed change to makesyscalls.sh

2018-08-05 Thread Martin Husemann
On Sun, Aug 05, 2018 at 06:24:25AM +0800, Paul Goyette wrote: > The primary usage for this is for arch/usermode's syscallemu() which > (according to those working on arch/usermode) could be considered > "dangerous" and "should never be autoloaded. Having this change will > allow use of a

Proposed change to makesyscalls.sh

2018-08-04 Thread Paul Goyette
I'd like to propose the following change to makesyscalls.sh to enable specifying a sys-call which _can_ be provided by a module, but only if the module is manually loaded. For these sys-calls, no entry is made in the autoload list, so the module will not be autoloaded. The primary usage for