On Sun, Nov 17, 2013 at 03:46:56PM -0800, John Nemeth wrote:
> We should be able to have modules
> in pkgsrc. There are no modules in pkgsrc yet, but
There are a handful and some have been there quite a while. I believe
at least some of them are now new-style modules rather than old-style
lkms
> Personally, I think the underlying structure of files should not be made
> visible to apps at all - they should just see a byte stream (perhaps with
> an advisory useful block size to write in).
i would buy this argument if mmap()ing a large sparse file
and filling it up randomly (but with rela
>> That's a reason to put it in the kernel, actually. The kernel can
>> tell which ranges of a file have already had space allocated for
>> them, so it can be just writes.
> Sure, but that's just an optimisation, and surely only matters if
> this is done enough that the difference is actually of s
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:
} >> > >I plan to import it and to make it available to both lua(1) and lua(4)
}
> Nobody would seriously claim, I think, that one can algorithmically
> determine whether a given fragment of Lua *source* code is malicious.
It is impossible, because the _very same code_ may be fairly called
malicious when presented for execution by an attacker but not when
presented for executi
On Sun, Nov 17, 2013 at 7:57 PM, Marc Balmer wrote:
> 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 availa
Date:Sun, 17 Nov 2013 23:49:50 +0100
From:Rhialto
Message-ID: <20131117224950.gh23...@falu.nl>
| Wasn't there some (proposed? actual?) interface to find holes in files?
I was told off-list about SEEK_HOLE and SEEK_DATA that allow (if the
filesys supports them) apps
> 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 the compiler wouldn't write. This c
On Mon 18 Nov 2013 at 05:11:35 +0700, Robert Elz wrote:
> how does it ever know whether or not there are
> holes to fill? And why would it do it that way, and follow by fallocate() ?
Wasn't there some (proposed? actual?) interface to find holes in files?
-Olaf.
--
___ Olaf 'Rhialto' Seibert -
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 the compiler wouldn't write. This can (1) cause a
Date:Sun, 17 Nov 2013 14:12:16 -0500 (EST)
From:Mouse
Message-ID: <201311171912.oaa17...@chip.rodents-montreal.org>
| That's a reason to put it in the kernel, actually. The kernel can tell
| which ranges of a file have already had space allocated for them, so it
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 lua(4)
>>>
>>> I wonder if we really
On Nov 17, 7:14pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| Humm.. I think that =A72.1 brings a good argument: "Standard Lua uses
| 64-bit integers and double-precision floats, (...)". I think that
| would not hurt to stick to
On Sun, Nov 17, 2013 at 6:45 PM, Justin Cormack
wrote:
> On Sun, Nov 17, 2013 at 8:39 PM, Lourival Vieira Neto
> wrote:
>> Well, I don't think I fully understood that; mainly because I'm not
>> aware about Lua 5.3. It will provide two number types for the scripts?
>> Or you are just talking about
> 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 the compiler wouldn't write. This can (1) cause a crash at load
time,
> > or it can (2) caus
On Sun, Nov 17, 2013 at 8:39 PM, Lourival Vieira Neto
wrote:
> Well, I don't think I fully understood that; mainly because I'm not
> aware about Lua 5.3. It will provide two number types for the scripts?
> Or you are just talking about lua_Integer type on the C-side. Lua 5.1
> already has a lua_In
On Sun, Nov 17, 2013 at 6:13 PM, Justin Cormack
wrote:
> On Sun, Nov 17, 2013 at 7:56 PM, Christos Zoulas wrote:
>> On Nov 17, 3:36pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
>> -- Subject: Re: [patch] changing lua_Number to int64_t
>>
>> | > 1. Lua 5.3 will have 64 bit integer sup
On Sun, Nov 17, 2013 at 7:56 PM, Christos Zoulas wrote:
> On Nov 17, 3:36pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
> -- Subject: Re: [patch] changing lua_Number to int64_t
>
> | > 1. Lua 5.3 will have 64 bit integer support as standard, which will
> | > make interop and reuse betw
On Nov 17, 3:36pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| > 1. Lua 5.3 will have 64 bit integer support as standard, which will
| > make interop and reuse between kernel and userspace code much easier,
| > iff we use int64_t
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 all this into NetBSD,
> > instead of moving it to pkgsrc
>> [...SIGXFSZ...]
>> It seems to me it would be more useful to do something like what
>> RLIMIT_CPU does, and generate SIGXFSZ for such operations, but fail
>> them only when the size exceeds the hard limit. [...]
> So I think the CPU limit signalling is treated as a special case
> because it's p
>>> [posix_fallocate]
>> We could fork a kernel thread that would go to userspace to do the
>> work with a write() loop, with appropriate credentials. Does it
>> makes sense?
> It would need to be a read/write loop, nothing says that there cannot
> already be blocks allocated in the space being fa
On Sat, Nov 16, 2013 at 12:40:22AM -0500, Mouse wrote:
> The documentation I have (which is consistent across 1.4T, 4.0.1, and
> 5.2) says that "[a] file I/O operation that would create a file larger
> that the process' soft limit will cause the write to fail and a signal
> SIGXFSZ to be genera
On Sun, Nov 17, 2013 at 10:33:43AM +0100, Emmanuel Dreyfus wrote:
> > To answer both you and the Mouse - the difference is that a user process
> > actually writing data consumes measurable resources, and thus is easy to
> > find and kill. When everything happens in the kernel, spotting which
On Sun, Nov 17, 2013 at 10:24:04AM +0100, Emmanuel Dreyfus wrote:
> > I think the chief question at this level is whether to support the
> > "keep the length" flag for fallocate, fdiscard, both, or neither. The
> > linux fallocate uses this to allow allocating blocks past EOF, which
> > strikes
On Sun, Nov 17, 2013 at 10:24:04AM +0100, Rhialto wrote:
> > I think the chief question at this level is whether to support the
> > "keep the length" flag for fallocate, fdiscard, both, or neither. The
>
> What "keep the length" flag? I don't see one at the indicated URL.
It's a linuxism in l
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 all this into NetBSD,
> instead of moving it to pkgsrc somehow.
This...
--
David A. Holland
dholl...@netbsd.org
On Sat, Nov 16, 2013 at 9:25 PM, Lourival Vieira Neto
wrote:
> (...) I moved strtoimax.c to common/libc. Don't know if
> someone sees a problem on that.
BTW, is it OK? Could someone review this?
Regards,
--
Lourival Vieira Neto
On Sun, Nov 17, 2013 at 3:10 PM, Justin Cormack
wrote:
> On Sun, Nov 17, 2013 at 4:52 PM, Lourival Vieira Neto
> wrote:
>> On Sun, Nov 17, 2013 at 2:02 PM, Christos Zoulas wrote:
>>> On Nov 17, 10:46am, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
>>> -- Subject: Re: [patch] changing lu
On Sun, Nov 17, 2013 at 4:52 PM, Lourival Vieira Neto
wrote:
> On Sun, Nov 17, 2013 at 2:02 PM, Christos Zoulas wrote:
>> On Nov 17, 10:46am, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
>> -- Subject: Re: [patch] changing lua_Number to int64_t
>>
>> | On Sun, Nov 17, 2013 at 7:37 AM, Ma
On Sun, Nov 17, 2013 at 2:02 PM, Christos Zoulas wrote:
> On Nov 17, 10:46am, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
> -- Subject: Re: [patch] changing lua_Number to int64_t
>
> | On Sun, Nov 17, 2013 at 7:37 AM, Marc Balmer wrote:
> | > Am 17.11.13 04:49, schrieb Terry Moore:
> |
On Nov 17, 10:46am, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| On Sun, Nov 17, 2013 at 7:37 AM, Marc Balmer wrote:
| > Am 17.11.13 04:49, schrieb Terry Moore:
| >> I believe that if you want the Lua scripts to be portable across
On Nov 17, 10:36am, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| I mean know it as a script programmer. I think that would be helpful
| to know the exact lua_Number width when you are writing a script.
| AFAIK, you don't have sizeo
On Sun, Nov 17, 2013 at 12:58 PM, Christos Zoulas wrote:
> On Nov 17, 1:36am, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
> -- Subject: Re: [patch] changing lua_Number to int64_t
>
> | > Bigger is better. And you can use %jd to print which is a big win.
> |
> | I agree that bigger is be
On Nov 17, 1:15pm, k...@munnari.oz.au (Robert Elz) wrote:
-- Subject: Re: posix_fallocate
| ps: I have not examined the FreeBSD implementation - if they've done it the
| hard, safe, way, and worked out all the potential kinks, and if it doesn't
| depend too much upon other aspects of their I/O sy
On Nov 17, 1:36am, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| > Bigger is better. And you can use %jd to print which is a big win.
|
| I agree that bigger is better and %jd is much better then "%" PRI/SCN.
| But don't you think
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 lua(4)
>>
>> I wonder if we really need to get all this into NetBSD,
>> instead of moving
On Sun, Nov 17, 2013 at 10:10 AM, Justin Cormack
wrote:
> On Sun, Nov 17, 2013 at 11:30 AM, Alexander Nasonov wrote:
>> Mouse wrote:
>>> Also, using an exact-width type assumes that the hardware/compiler in
>>> question _has_ such a type.
>>>
>>> It's possible that lua, NetBSD, or the combination
On Sun, Nov 17, 2013 at 9:30 AM, Alexander Nasonov wrote:
> Mouse wrote:
>> Also, using an exact-width type assumes that the hardware/compiler in
>> question _has_ such a type.
>>
>> It's possible that lua, NetBSD, or the combination of the two is
>> willing to write off portability to machines wh
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 handle structured
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/
>>
>> I plan to import it and
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 import it and to make it available to both lua
On Sun, Nov 17, 2013 at 8:52 AM, Alexander Nasonov wrote:
> Marc Balmer wrote:
>> The basic issue here is that Lua has only _one_ numerical data type,
>> which is an integral type in kernel, but a floating point type in userspace.
>
> Right, not everyone here knows this I guess. Thanks for making
On Sun, Nov 17, 2013 at 7:37 AM, Marc Balmer wrote:
> Am 17.11.13 04:49, schrieb Terry Moore:
>> I believe that if you want the Lua scripts to be portable across NetBSD
>> deployments, you should choose a well-known fixed width.
>
> I don't see this as very important. Lua scripts will hardly depe
On Sun, Nov 17, 2013 at 7:35 AM, Marc Balmer wrote:
> Am 17.11.13 04:36, schrieb Lourival Vieira Neto:
>> On Sat, Nov 16, 2013 at 10:44 PM, Christos Zoulas
>> wrote:
>>> On Nov 16, 9:30pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
>>> -- Subject: Re: [patch] changing lua_Number to i
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.
- Hubert
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 import it and to make it available to both lua(1) and lua(4)
> as follows:
>
> The source code wi
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/
>
> I plan to import it and to make it available to both lua(1) and lua(4)
> as
On Sun, 17 Nov 2013, Mouse wrote:
sizeof returns the number of bytes used to store an object.
This is only loosely related to the number of data bits in the
object; the latter is no more than sizeof the object times
CHAR_BIT, but it may be lower.
Also, using an exact-width type assumes that t
On Sun, Nov 17, 2013 at 11:30 AM, Alexander Nasonov wrote:
> Mouse wrote:
>> Also, using an exact-width type assumes that the hardware/compiler in
>> question _has_ such a type.
>>
>> It's possible that lua, NetBSD, or the combination of the two is
>> willing to write off portability to machines w
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
Date:Sun, 17 Nov 2013 10:33:43 +0100
From:m...@netbsd.org (Emmanuel Dreyfus)
Message-ID: <1lch6me.jn7y3m16232ejm%m...@netbsd.org>
| We could fork a kernel thread that would go to userspace to do the work
| with a write() loop, with appropriate credentials. Does it
Mouse wrote:
> Also, using an exact-width type assumes that the hardware/compiler in
> question _has_ such a type.
>
> It's possible that lua, NetBSD, or the combination of the two is
> willing to write off portability to machines where one or both of those
> potential portability issues becomes a
Marc Balmer wrote:
> The basic issue here is that Lua has only _one_ numerical data type,
> which is an integral type in kernel, but a floating point type in userspace.
Right, not everyone here knows this I guess. Thanks for making it clear.
> > Also, some libraries work in both spaces. Lua bindi
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
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 just like userspace lua_Numbers could lead to misund
>> I agree that bigger is better and %jd is much better then "%"
>> PRI/SCN. But don't you think that to know the exact width is even
>> better?
> You can always use sizeof if the need to know the size arises.
sizeof returns the number of bytes used to store an object. This is
only loosely relat
On Sat, Nov 16, 2013 at 12:40:22AM -0500, Mouse wrote:
> The documentation I have (which is consistent across 1.4T, 4.0.1, and
> 5.2) says that "[a] file I/O operation that would create a file larger
> that the process' soft limit will cause the write to fail and a signal
> SIGXFSZ to be generated"
>> I think the chief question at this level is whether to support the
>> "keep the length" flag for fallocate, fdiscard, both, or neither.
>> The linux fallocate uses this to allow allocating blocks past EOF,
>> which strikes me as nuts;
> Why is it bad?
Well, I'm not dholland. But my own answer
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
Am 17.11.13 04:49, schrieb Terry Moore:
> I believe that if you want the Lua scripts to be portable across NetBSD
> deployments, you should choose a well-known fixed width.
I don't see this as very important. Lua scripts will hardly depend on
the size of an integer.
> Watch out, by the way, for
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
Am 17.11.13 04:36, schrieb Lourival Vieira Neto:
> On Sat, Nov 16, 2013 at 10:44 PM, Christos Zoulas wrote:
>> On Nov 16, 9:30pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
>> -- Subject: Re: [patch] changing lua_Number to int64_t
>>
>> | On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoula
Robert Elz wrote:
> To answer both you and the Mouse - the difference is that a user process
> actually writing data consumes measurable resources, and thus is easy to
> find and kill. When everything happens in the kernel, spotting which
> arrantly idle user process is making it happen is not
Date:Sun, 17 Nov 2013 08:05:03 +
From:David Holland
Message-ID: <20131117080503.gb7...@netbsd.org>
| I don't see how this is a DoS attack that e.g. dd if=/dev/urandom
| of=/dev/null isn't.
To answer both you and the Mouse - the difference is that a user proce
On Sun 17 Nov 2013 at 07:59:44 +, David Holland wrote:
> I think the chief question at this level is whether to support the
> "keep the length" flag for fallocate, fdiscard, both, or neither. The
What "keep the length" flag? I don't see one at the indicated URL.
The way I read it, the call ju
David Holland wrote:
> I think the chief question at this level is whether to support the
> "keep the length" flag for fallocate, fdiscard, both, or neither. The
> linux fallocate uses this to allow allocating blocks past EOF, which
> strikes me as nuts;
Why is it bad?
I am interested to port
On Sun, Nov 17, 2013 at 01:15:14PM +0700, Robert Elz wrote:
> Alternatively, the system could actually allocate all required blocks at
> the time of the posix_fallocate() call - effectively filling in any holes
> in the designated region of the file. The spec doesn't say what data is
> to be
On Sun, Nov 17, 2013 at 02:02:15AM +0100, Emmanuel Dreyfus wrote:
> NetBSD-current seems to lack posix_fallocate(2)
> http://pubs.opengroup.org/onlinepubs/009695299/functions/posix_fallocate
> .html
>
> Is someone already working on it, or has thoughs about how it should be
> implemented?
I
70 matches
Mail list logo
