> Am 10.09.2017 um 12:35 schrieb Maxime Villard :
>
> Le 10/09/2017 à 12:24, Paul Goyette a écrit :
>> On Sun, 10 Sep 2017, Maxime Villard wrote:
>>> Re-thinking about this again, it seems to me we could simply add a flags
>>> field in modinfo_t, with a bit that says "if this module is builtin, t
> [1] is a patch that removes luactl command to require a module; as
> Mark suggested, it should be up to the script being loaded to issue
> 'require' on modules.
>
> [1] https://netbsd.org/~salazar/patches/bye_require.patch
>
> Comments?
- The manpage date fields needs to be bumped to reflect
A few more thoughts on this:
In fact we should actually remove the option to require modules into staes from
the command line completely.
After all it is up to the code being loaded to „decide“ what it requires and
what not.
Maybe we could have some white- or blacklist that defines which module
> Am 21.05.2016 um 15:50 schrieb Guilherme Salazar :
>
> On Sat, May 21, 2016 at 10:27 AM, Marc Balmer wrote:
>> Where was this discussed? Are you referring to the email discussion we had?
>
>
> No; I'm not referring to our discussion. Please
Hi
> Am 21.05.2016 um 00:27 schrieb Guilherme Salazar :
>
> Hi folks,
>
> kernel Lua states created with luactl(8) are created empty. There has
> been some discussion about it.
Where was this discussed? Are you referring to the email discussion we had?
>
> It would be nice to add an option t
Good Morning!
Am 10.09.15 um 13:57 schrieb Masanobu SAITOH:
> On 2015/09/10 17:24, Martin Husemann wrote:
>> On Thu, Sep 10, 2015 at 10:21:01AM +0200, Marc Balmer wrote:
>>> I used to start a netbsd-6 machine by sending Wake-on-LAN frames wo it.
>>>
>>> Afte
I used to start a netbsd-6 machine by sending Wake-on-LAN frames wo it.
After upgrading that machine to netbsd-7, it ignores these WoL packages and
does not start.
Its an i386 with bge(4) interface (a HP micro server).
Something must have changed in how netbsd shutsdown -p a machine.
And ideas?
Am 26.05.15 um 09:20 schrieb Ryota Ozaki:
> Hi,
>
> The next sacrifice is ARCNET. It seems it hasn't been
> used for long years (7 years or more):
> http://mail-index.netbsd.org/source-changes/2015/05/22/msg066175.html
>
> So I'm trying to remove them but the target files are
> much more than I
Am 10.05.15 um 23:10 schrieb Kamil Rytarowski:
> Well, I like /dev/happy for Happy Number generator. What would be the
> better name?
/dev/":)" ...
Am 15.02.15 um 16:31 schrieb Maxime Villard:
> Le 14/02/2015 08:40, David Holland a écrit :
>> On Fri, Feb 13, 2015 at 07:05:00PM +0100, Maxime Villard wrote:
>> > > Our norms for significant changes are more or less about consensus or
>> > > preponderance of opinion. So far you've said that y
Am 13.02.15 um 12:35 schrieb Maxime Villard:
> Apparently, compat-FreeBSD is needed by tw_cli users.
>
> Therefore I think I will just disable it by default in the GENERIC kernels,
> unless anyone disagrees.
I disagree. People still use it.
Am 13.02.15 um 12:34 schrieb Maxime Villard:
> Le 09/02/2015 10:12, Marc Balmer a écrit :
>>> I intend to remove the compat-FreeBSD support from the system.
>>> [...]
>>> This is what motivates my proposal.
>>>
>>> Ok?
>>
>> Generally
> I intend to remove the compat-FreeBSD support from the system.
> [...]
> This is what motivates my proposal.
>
> Ok?
Generally it would be a good idea, but there are obviously some tw_cli
users. So they need a working alternative first, imo. Maybe 3Ware
would help, if being asked?
> Hi Alexander,
>
> On Sat, Jul 12, 2014 at 5:01 PM, Alexander Nasonov wrote:
>> Lourival Vieira Neto wrote:
>>> Hi folks,
>>>
>>> Here are some pending patches which I want to commit:
>>> http://www.netbsd.org/~lneto/pending/. Please, could someone review
>>> them?
>>>
>>> Thank you in advanc
Am 07.02.14 10:40, schrieb Michael van Elst:
> m...@msys.ch (Marc Balmer) writes:
>
>> The other proposed "solution", namely to add a delay to open in case the
>> device is reopened, does not help either in the use cases where we run
>> into trouble:
>
>&g
Am 06.02.14 17:18, schrieb Marc Balmer:
> Closing a serial port (e.g. /dev/dtyXX) takes almost exactly one second.
> Why is that so? Why does the call not return immediately?
>
> int fd;
>
> fd = open("/dev/dty03", O_RDWR); /* returns immediately */
> close(f
Am 06.02.14 21:08, schrieb Dennis Ferguson:
>
> On 6 Feb, 2014, at 11:16 , Matthias Drochner wrote:
>> On Thu, 6 Feb 2014 19:50:04 +0100
>> Marc Balmer wrote:
>>> If I find the spot, I will probably remove it.
>>
>> It is line 784 in dev/ic/com.c. It depe
Am 06.02.14 21:05, schrieb Brian Buhrow:
> hello. The com(4) driver is pretty well vetted in the NetBSD
> sys/dev/ic tree. In my opinion, the 1 second delay was put there for a
> reason when something didn't work and the Sparc driver would get it in a
> new york minute if it had been used i
Am 06.02.14 20:47, schrieb Matthias Drochner:
>
> On Thu, 6 Feb 2014 20:24:52 +0100
> Marc Balmer wrote:
>> If, at all, the application using the driver should sleep for one
>> second after closing the device before reopening it.
>
> Not that I care too much about mo
Am 06.02.14 20:16, schrieb Matthias Drochner:
>
> On Thu, 6 Feb 2014 19:50:04 +0100
> Marc Balmer wrote:
>> If I find the spot, I will probably remove it.
>
> It is line 784 in dev/ic/com.c. It depends on the HUPCL
> flag unset which is done around line 1344, depen
Am 06.02.14 19:20, schrieb Matthias Drochner:
>
> On Thu, 6 Feb 2014 18:51:38 +0100
> Marc Balmer wrote:
>> I see the 1 sec delay also when the device is set to local mode.
>
> Also with softcar? From my /etc/ttys:
> tty00 "/usr/libexec/getty std.9600"
Am 06.02.14 18:08, schrieb Dennis Ferguson:
>
> On 6 Feb, 2014, at 08:18 , Marc Balmer wrote:
>> Closing a serial port (e.g. /dev/dtyXX) takes almost exactly one second.
>> Why is that so? Why does the call not return immediately?
>>
>> int fd;
>>
>> fd
Closing a serial port (e.g. /dev/dtyXX) takes almost exactly one second.
Why is that so? Why does the call not return immediately?
int fd;
fd = open("/dev/dty03", O_RDWR); /* returns immediately */
close(fd); /* returns after one second */
Some Illumos developers consider adding Lua to the kernel to provide
what they call ZFS Channel Programs:
http://www.youtube.com/watch?v=EGKek5sZ2Xw&list=PLaUVvul17xSdWMBt5tAC8Hu7bbeWskD_q
Lua part starts at approx 1:13
Am 29.11.13 12:38, schrieb Lourival Vieira Neto:
>> It will be interesting to see by how much memory the addition of the
>> standard libraries will grow lua(4). lneto claims it does not grow at
>> all. If it should, we can still move the standard libraries to a kmod.
>
> I just double checked no
Am 28.11.13 23:19, schrieb Alexander Nasonov:
>> Yes, I understand this but I don't understand why to you need a special
>> control for it. It's your choice as a programmer to call that function
>> or not to call. Why do you need a special variable/syscal to control this?
>
> Ok, I missed luactl(
Am 28.11.13 22:52, schrieb Lourival Vieira Neto:
>> If the standard libraries should be a separate kmod or if the code
>> should just reside in lua(4) is another question.
>
> I really see no reason to put it in another kmod. Moreover, following
> the user-space analogy argument, liblua is linked
fine by me
Freundliche Grüsse,
Marc Balmer
--
Marc Balmer
micro systems, Landstrasse 66, CH-5073 Gipf-Oberfrick
Tel.: +41 62 871 45 65, http://www.msys.ch/
arcapos(r) Kassensystem: http://www.arcapos.ch/
Am 28.11.2013 um 22:52 schrieb Lourival Vieira Neto :
>> If the standard libraries
Am 28.11.13 22:17, schrieb Alexander Nasonov:
> Marc Balmer wrote:
>> Am 27.11.13 22:23, schrieb Martin Husemann:
>>
>>> Can't it be a per-state option, passed by luactl when creating the state?
>>
>> That is actually an excellent idea. So what should
Am 27.11.13 22:23, schrieb Martin Husemann:
> Can't it be a per-state option, passed by luactl when creating the state?
That is actually an excellent idea. So what should be the default,
stdlibs enabled or not enabled?
- Marc
(given that aio does not work either as
expected).
> Marc Balmer wrote:
>> What is the prupose or reasoning behind the fact that multiple processes
>> can open a message queue for reading using mq_open()?
>>
>> I wrote simple mq sender and mq receiver programs; when I sta
Am 26.11.13 12:13, schrieb Lourival Vieira Neto:
> Hi Marc,
>
> On Tue, Nov 26, 2013 at 6:18 AM, Marc Balmer wrote:
>> Am 26.11.13 02:50, schrieb Lourival Vieira Neto:
>>> Hi Folks,
>>>
>>> Here is a patch that puts some Lua standard libraries into the
What is the prupose or reasoning behind the fact that multiple processes
can open a message queue for reading using mq_open()?
I wrote simple mq sender and mq receiver programs; when I start multiple
receivers on the same mq, and send a message to it, only one of the
receivers gets the message, in
Am 26.11.13 03:26, schrieb Lourival Vieira Neto:
> Hi again..
>
> Just a tiny patch to use luaL_register() on luacore kernel module.
>
> Regards
You are now using the auxiliary library, which I did not include in
kernel Lua on prupose (to keep stuff smaller).
So what is the gain of including th
Am 26.11.13 02:50, schrieb Lourival Vieira Neto:
> Hi Folks,
>
> Here is a patch that puts some Lua standard libraries into the kernel:
>
> - Auxiliary library (C API);
> - Base library;
> - String library;
> - Table library.
In the kernel, Lua states are created empty _on purpose_. So the Lua
Am 18.11.13 00:46, schrieb John Nemeth:
> On Nov 17, 11:02pm, Marc Balmer wrote:
> } Am 17.11.13 20:40, schrieb Lourival Vieira Neto:
> } > On Sun, Nov 17, 2013 at 4:39 PM, David Holland
> wrote:
> } >> On Sun, Nov 17, 2013 at 01:32:03PM +0100, Hubert Feyrer wrote:
> }
Am 20.11.13 13:33, schrieb Lourival Vieira Neto:
> On Wed, Nov 20, 2013 at 6:36 AM, Marc Balmer wrote:
>> Am 18.11.13 09:07, schrieb Marc Balmer:
>>> Am 17.11.13 13:05, schrieb Marc Balmer:
>>>> I came accross a small library for converting data to an from C st
Am 20.11.13 10:26, schrieb Justin Cormack:
>
> On 20 Nov 2013 08:38, "Marc Balmer" mailto:m...@msys.ch>>
> wrote:
>> > Now we need a name that covers both uses cases. It could be "memory"
>> > because it deals with memory, or just &
Am 18.11.13 09:07, schrieb Marc Balmer:
> Am 17.11.13 13:05, schrieb Marc Balmer:
>> I came accross a small library for converting data to an from C structs
>> for Lua, written by Roberto Ierusalimschy:
>>
>> http://www.inf.puc-rio.br/~roberto/struct/
>>
>
Am 17.11.13 13:05, schrieb Marc Balmer:
> I came accross a small library for converting data to an from C structs
> for Lua, written by Roberto Ierusalimschy:
>
> http://www.inf.puc-rio.br/~roberto/struct/
>
> I plan to import it and to make it available to both lua(1) and l
Am 17.11.13 22:03, schrieb Terry Moore:
>> From: Marc Balmer [mailto:m...@msys.ch]
>>
>>> It's not *much* less safe than compiling and executing a string in the
>>> kernel. The only additional attack surfaces are that you can write
> things
>>> that
Am 17.11.13 20:40, schrieb Lourival Vieira Neto:
> On Sun, Nov 17, 2013 at 4:39 PM, David Holland
> wrote:
>> On Sun, Nov 17, 2013 at 01:32:03PM +0100, Hubert Feyrer wrote:
>> > >I plan to import it and to make it available to both lua(1) and lua(4)
>> >
>> > I wonder if we really need to get
Am 17.11.13 14:43, schrieb Lourival Vieira Neto:
> On Sun, Nov 17, 2013 at 11:23 AM, Marc Balmer wrote:
>> Am 17.11.13 13:32, schrieb Hubert Feyrer:
>>> On Sun, 17 Nov 2013, Marc Balmer wrote:
>>>> I plan to import it and to make it available to both lua(1) and
Am 17.11.13 13:32, schrieb Hubert Feyrer:
> On Sun, 17 Nov 2013, Marc Balmer wrote:
>> I plan to import it and to make it available to both lua(1) and lua(4)
>
> I wonder if we really need to get all this into NetBSD,
> instead of moving it to pkgsrc somehow.
Yes, we need it to
Am 17.11.13 13:20, schrieb Justin Cormack:
> On Sun, Nov 17, 2013 at 12:05 PM, Marc Balmer wrote:
>> I came accross a small library for converting data to an from C structs
>> for Lua, written by Roberto Ierusalimschy:
>>
>> http://www.inf.puc-rio.br/~roberto/struct/
&g
Am 17.11.13 13:21, schrieb Alexander Nasonov:
> Marc Balmer wrote:
>> I came accross a small library for converting data to an from C structs
>> for Lua, written by Roberto Ierusalimschy:
>>
>> http://www.inf.puc-rio.br/~roberto/struct/
>>
>> I plan to imp
I came accross a small library for converting data to an from C structs
for Lua, written by Roberto Ierusalimschy:
http://www.inf.puc-rio.br/~roberto/struct/
I plan to import it and to make it available to both lua(1) and lua(4)
as follows:
The source code will be imported into
${NETBSDSRCDIR}/s
Am 17.11.13 11:18, schrieb Alexander Nasonov:
> Lourival Vieira Neto wrote:
>> I don't think that keeping compatibility with userspace Lua is the
>> right argument. We already have lost this kind of compatibility by
>> using an integer type for lua_Number. Expecting that kernel lua_Number
>> works
Am 17.11.13 06:30, schrieb Terry Moore:
>> From: Lourival Vieira Neto [mailto:lourival.n...@gmail.com]
>>> Watch out, by the way, for compiled scripts; I have not checked Lua 5.x,
> but
>>> you may find if not careful that the compiled binary is not loadable on
>>> machines with different choices f
te:
>>> -- Subject: Re: [patch] changing lua_Number to int64_t
>>>
>>> | On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoulas
>> wrote:
>>> | > In article <52872b0c.5080...@msys.ch>, Marc Balmer
>> wrote:
>>> | >>Changing the number ty
Am 17.11.13 00:47, schrieb Alexander Nasonov:
> PS Why do you still use a shadow copy of luaconf.h? Please add your
> changes to the main luaconf.h. If you guard your kernel changes properly
> with _KERNEL, they will not affect userspace.
I totally agree. It was probably just an oversight when I
, 2013 at 8:52 PM, Christos Zoulas
>> wrote:
>> | > In article <52872b0c.5080...@msys.ch>, Marc Balmer wrote:
>> | >>Changing the number type to int64_t is certainly a good idea. Two
>> | >>questions, however:
>> | >
>> | > Why no
Changing the number type to int64_t is certainly a good idea. Two
questions, however:
1) Why do you remove the sys/modules/lua/inttypes.g file?
2) In sys/modules/lua/luaconf.h, lua_str2number is still #defined as
stroll(), which assumes long long. Shouldn't that be changed as well to
a function
Am 30.10.13 10:00, schrieb Alan Barrett:
> On Tue, 29 Oct 2013, John Nemeth wrote:
>> The default path for module loading is: /stand/amd64-xen/6.99.25/modules
>
> I suggest exposing the path via sysctl, and printing the sysctl mib name
> in the message, something like
>
> kern.module.path=/st
Am 30.10.13 07:49, schrieb John Nemeth:
> I've made a patch to the module subsystem to print the default
> module load path during initialisation. The reason for doing this
> is that certain arch/machine combos don't work with the standard
> modules for their archs and require custom built mo
Kernel from freshly built sources from this morning on amd64 hangs
during boot.
Last message:
xhci0: xhci_open addr 0 depth 0 port 0 speed 3
Am 19.10.13 00:51, schrieb John Nemeth:
> } kern.lua.autoload is a safety barrier. One may wish not allow any lua kernel
> } script to load any given lua kernel module.
>
> The lua(4) implementers can certainly do this if they want.
> However, module_autoload() won't be looking at this flag
Am 21.10.13 00:05, schrieb Christoph Badura:
> On Tue, Oct 15, 2013 at 06:01:29PM -0300, Lourival Vieira Neto wrote:
>>> Also, having to switch mentally between zero-based arrays in the kernel C
>>> code and 1-based arrays in the Lua code make my head ache.
>> It's something that doesn't bug me so
Am 21.10.13 07:57, schrieb Artem Falcon:
[...]
> Doing w/o a diff, i don't have a sane mail environment now to send it inline.
>
> There's few more things.
> First: you forgot to add MODULE_CLASS_LUA_BINDING to a
> sys/sys/module.h.
FWIW, I removed the MODULE_CLASS_LUA_BINDING and use the exist
Am 21.10.13 21:22, schrieb Alexander Nasonov:
> Marc Balmer wrote:
>> Yes, this is an issue. Dunno if we need a 'kluac' or so, at the moment
>> I'd say loading code from source form is ok.
>
> Supporting binary chunks is more challenging because binary format
Am 21.10.13 07:57, schrieb Artem Falcon:
[...]
>
> There's few more things.
> First: you forgot to add MODULE_CLASS_LUA_BINDING to a
> sys/sys/module.h.
I merely forgot to commit it, thats fixed now.
> Second: kernel side Lua will reject to load bytecode produced by luac cause
> the first built
Am 19.10.13 14:02, schrieb Alexander Nasonov:
[...]
> Lets say you want to iterate over all "ps" processes from ddb (if gdb
> has python support, why can't we have a cooler thing?). You do this:
>
> ddb> lua on
> ddb> for p in processes:match("ps") do print(p.pid) end
> 906
> 2245
> 4935
> ...
>
Am 19.10.13 09:12, schrieb Alan Barrett:
> On Fri, 18 Oct 2013, Lourival Vieira Neto wrote:
>>> I have to point out that "interesting work" is commonly used as a
>>> sort of euphemism to refer to highly experimental work with unclear
>>> future.
>>
>> Yes. But I'm talking about "interesting *user*
Am 19.10.13 09:03, schrieb Alan Barrett:
> On Sat, 19 Oct 2013, Marc Balmer wrote:
>> The inclusion and use of Lua in base, for use in userland and the
>> kernel, [...] has, last but not least, core's blessing.
>
> Would you please either present some evidence for that c
Am 19.10.13 00:14, schrieb Aleksej Saushev:
[...]
> I'm of opinion that this device driver can and should stay outside the tree
> until its utility can be demonstrated without this much strain.
> At last this is one of the reasons why we support kernel modules.
The inclusion and use of Lua in ba
Am 18.10.13 10:43, schrieb Artem Falcon:
> Marc Balmer msys.ch> writes:
>>>> Justin Cormack specialbusservice.com> writes:
>>>> I have been using the luajit ffi and luaffi, which let you directly
>>>> use C structs (with bitfields) in Lua to do this
Am 16.10.13 16:41, schrieb Lourival Vieira Neto:
> Hi Justin,
>
> On Tue, Oct 15, 2013 at 7:38 PM, Justin Cormack
> wrote:
>> On Thu, Oct 10, 2013 at 7:15 PM, Lourival Vieira Neto
>> wrote:
>>> Hi folks,
>>>
>>> It has been a long time since my GSoC project and though I have tried
>>> to come ba
Am 15.10.13 23:01, schrieb Lourival Vieira Neto:
[...]
>> Also, having to switch mentally between zero-based arrays in the kernel C
>> code and 1-based arrays in the Lua code make my head ache.
>
> It's something that doesn't bug me so much.. But, if necessary it
> could be changed to 0-based in
Am 15.10.13 09:40, schrieb Martin Husemann:
> On Tue, Oct 15, 2013 at 12:18:15AM -0700, Matt Thomas wrote:
>>
>> On Oct 15, 2013, at 12:09 AM, Marc Balmer wrote:
>>> Is that possible?
>>
>> No.
>
> If you only need it as a hint (like for naming a wchan
In a tty line discipline, I want to get the name of the tty driver
instance, e.g. "dtyU0". The line disciplines are called with a "struct
tty *" as argument, is there any (halfway sane) way to get at the name
of the driver instance? I need the name of the instance, not only the
name of the driver
Am 15.10.13 00:21, schrieb Mouse:
>> -current is where development should take place.
>
> I disagree. That way - doing development in the master tree - lies the
> madness that has given Linux some of its worst problems. Development
> should take place on branches, or, preferably, outside the m
Am 11.10.13 09:19, schrieb David Holland:
> > lua(4) comes with examples.
>
> Such as?
- Several examples om how to use kernel mode Lua, like how to provide
and use modules, call module functions etc.
- tty(4) line disciplines written in Lua, decoding serial data
- "Obscure" GPIO stuff that I d
Taylor,
>I found out that several programs already have Lua bindings, but for
>unknown reasons that code is not enabled by default, which is kind of
>weird given that the Lua library is in base... So we have Lua bindings
>in our code, whe have Lua as well, but yet we don't enable
Am 09.10.13 10:53, schrieb Justin Cormack:
> On Wed, Oct 9, 2013 at 9:26 AM, Thomas Klausner wrote:
>> On Wed, Oct 09, 2013 at 08:37:23AM +0200, Marc Balmer wrote:
>>> So if no one really objects the plan is as follows:
>>>
>>> - Import Lua 5.2 to src/sys/ext
Am 09.10.13 10:26, schrieb Thomas Klausner:
> On Wed, Oct 09, 2013 at 08:37:23AM +0200, Marc Balmer wrote:
>> So if no one really objects the plan is as follows:
>>
>> - Import Lua 5.2 to src/sys/external/
>> - Remove Lua 5.1 from src/external/
>
> apb suggested
Am 06.10.13 21:59, schrieb Marc Balmer:
> I am in the progress of
>
> - Updating the Lua code in base from version 5.1 to version 5.2
> - Commiting the kernel parts from our GSoC project, "Lua in the NetBSD
> Kernel"
>
> mrg@ suggestest that I move the Lua so
Hi All
I am in the progress of
- Updating the Lua code in base from version 5.1 to version 5.2
- Commiting the kernel parts from our GSoC project, "Lua in the NetBSD
Kernel"
mrg@ suggestest that I move the Lua source code from src/external/ to
src/sys/external, which imo makes sense. Comments r
Am 01.05.13 15:49, schrieb dinesh thangavel:
> Hi,
> Based on my discussion in IRC with Michael Balmer, I can develop a
> driver for I2C based LCD device during GSoC period. This driver will
> provide a tty like interface. I will extend this to a LCD framework
> after GSoC period as it seems to b
Am 24.02.2013 um 10:15 schrieb Mouse :
>> FWIW, _all_ of my NetBSD systems run PostgreSQL and thus require that
>> stuff.
>
> And none of mine do - but all of mine require AF_TIMER sockets, which I
> don't see NetBSD hurrying to adopt.
>
> I don't think any one person's use cases are a useful g
>>> Like mouse@ I am unaware of what makes ksem mandatory, [...]
>> Whatever is 'mandatory'.
>
> Well, it was said to be...as jnemeth put it, it was "made unconditional
> on the basis that it is essential".
>
>> But if you use programs that require POSIX shared memory, you should
>> also offer PO
Am 12.01.2013 um 21:15 schrieb Ryo ONODERA :
> Hi,
>
> From: Marc Balmer , Date: Mon, 7 Jan 2013 22:11:38 +0100
>
>>
>> I want to import the lua(4) device driver, which is currently a module only,
>> which seems wrong.
>>
>> Is sys/dev/lua/ a good
Am 09.01.2013 um 22:07 schrieb Alexander Nasonov :
> Marc Balmer wrote:
>> Sure. The full diff is at
>> http://www.netbsd.org/~mbalmer/diffs/kernel_lua_010.diff and it's the files
>> that the diff now places in sys/modules/lua/ that I think should better go
>
Am 09.01.2013 um 16:28 schrieb matthew green :
>
>> I want to import the lua(4) device driver, which is currently a module only,
>> which seems wrong.
>>
>> Is sys/dev/lua/ a good place?
>
> can you give a little more details on what is included?
Sure. The full diff is at
http://www.netbsd.
I want to import the lua(4) device driver, which is currently a module only,
which seems wrong.
Is sys/dev/lua/ a good place?
Am 29.12.2012 um 14:57 schrieb Paul Goyette :
> On Sat, 29 Dec 2012, Marc Balmer wrote:
>
>>> this is going to upset dyoung i'm sure :) but it seems to me that
>>> if these invasive changes to individual subsystems are needed like
>>> this, and we want the
Am 29.12.2012 um 12:47 schrieb matthew green :
>
>> Which is fine for gpiosim, as it can just depend on the lua
>> module. For LINEDISC_LUA, there would have to be some kind of hook to
>> which the lua module would attach when loaded, so that the kernel would
>> still function even without
> this is going to upset dyoung i'm sure :) but it seems to me that
> if these invasive changes to individual subsystems are needed like
> this, and we want them to be optional, then imo they should be on
> a per-subsystem basis, not global. eg something like:
>
> options LINEDISC_LUA
>
Am 28.12.2012 um 12:19 schrieb John Nemeth :
> On May 20, 6:34am, Marc Balmer wrote:
> } Am 28.12.2012 um 11:43 schrieb Jukka Ruohonen :
> } > On Fri, Dec 28, 2012 at 11:35:05AM +0100, Marc Balmer wrote:
> } >>> What does this mean? Also the kernel modu
Am 28.12.2012 um 11:43 schrieb Jukka Ruohonen :
> On Fri, Dec 28, 2012 at 11:35:05AM +0100, Marc Balmer wrote:
>>> What does this mean? Also the kernel modules using lua(4) will be
>>> conditionally compiled? I think this is fairly strongly against the design
>&
> On Fri, Dec 28, 2012 at 10:05:36AM +0100, Marc Balmer wrote:
>> Using a kernel module is not possible in all cases.
>
> By a closer look, you have:
>
> +#ifdef LUA
> +MODULE(MODULE_CLASS_DRIVER, gpiosim, "gpio,lua");
> +#else
>
Am 28.12.2012 um 00:50 schrieb David Young :
> On Mon, Dec 24, 2012 at 10:43:03AM +0100, Marc Balmer wrote:
>> For such more invasive changes, I foresee to use a kernel option, 'options
>> LUA' which will compile such code only when the option is enabled. It wil
Brian,
> Hello. I'm not going to call myself an expert on such things, but it
> seems like a better design would be to write a module that acts as a bridge
> to the lua environment. That is, write a lua function that actually maps
> to the tty functions you want to access in the kernel and
> A good part of Lua in the kernel is non-invasive, i.e. it consists of
> software that you can use or not. These parts, namely the lua(4) device
> driver, the Lua kernel modules that provide Lua bindings to the kernel, and
> the luactl(8) utility, are non-critical since they are "stand-alone"
A good part of Lua in the kernel is non-invasive, i.e. it consists of software
that you can use or not. These parts, namely the lua(4) device driver, the Lua
kernel modules that provide Lua bindings to the kernel, and the luactl(8)
utility, are non-critical since they are "stand-alone" without
Am 15.12.2012 um 23:05 schrieb Iain Hibbert :
> On Sat, 15 Dec 2012, Marc Balmer wrote:
>
>> The attached small driver adds support for the cash drawer port found on
>> the PROTECH PS3100 point of sale terminal by providing a gpio(4) device
>> with two pins. Pin 0 con
. Comments welcome.
- Marc Balmer
PS: A picture of a PS3100 can be found here: http://www.arcapos.ch/ps3100, the
datasheet here http://www.arcapos.ch/ps3100/PS3100.pdf.
ptcd.diff.gz
Description: GNU Zip compressed data
Am 05.03.12 20:41, schrieb Edgar Fuß:
> After the recent problems[*] we've been having with our (4.0/amd64) file
> server, I'll surely be facing the question why we're not using that other OS
> everybody else does.
You sureley mean an up-to-date version of NetBSD, right? btw, if you
would fold
Am 09.01.12 09:13, schrieb Emmanuel Dreyfus:
> On Mon, Jan 09, 2012 at 08:27:04AM +0100, Marc Balmer wrote:
>> Have you realized that these drivers are apparently GPL/LGPL and
>> thus not suitable for NetBSD kernel inclusion?
>
> Don't we have LKM and pkgsrc just for tha
Am 09.01.2012 03:06, schrieb Emmanuel Dreyfus:
Hello everybody
PCI boards for Asterisk require kernel drivers, which used to be
provided by the now obsolete and retired zaptel package. We now need
DADHI drivers, which have a FreeBSD port here:
http://svn.digium.com/svn/dahdi/freebsd/trunk
Anyon
In the syscal wrapper, only return values when the syscall did not
return an error.
Comments?
Index: sys/kern/kern_ktrace.c
===
RCS file: /cvsroot/src/sys/kern/kern_ktrace.c,v
retrieving revision 1.158
diff -u -r1.158 kern_ktrace.c
--
1 - 100 of 152 matches
Mail list logo
