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 claim, or
stop making the claim.
To the best of my knowledge, userland Lua
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* work". I'm not
claiming that they should be in the kern
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 claim, or stop
> making the
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*
marc@ wrote:
> Me and others are giving answers. It just seem so that it is not the
> answers some people want to hear.
Probably many people want to see an actual sample implementation,
like a dumb device driver that blinks LEDs via GPIO etc. using
integrated Lunatik APIs, like computer textbook
On Oct 19, 2013, at 12:26 AM, Marc Balmer wrote:
> 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
On Sat, 19 Oct 2013, Marc Balmer wrote:
And now to give you a practical example what I personally do with lua(4)
right now: In the past I wrote several tty line disciplines to decode
various serial formats. Now I have a need for that again. Doing this
in C is of course possible, but I want som
18.10.2013, в 21:03, John Nemeth написал(а):
> On Oct 18, 11:03am, Marc Balmer wrote:
> } 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 direct
On a FFSv2/WAPBL file system successfully fsck -f'd less than two hours
before, I got a "bad dir: mangled entry" panic.
I fsck'd again, finding missing dot/dotdot entries and a bunch of unconnected
files.
Just within minutes after going live again, I experienced the same panic,
and fsck found mis
Le 19/10/13 00:47, Marc Balmer a écrit :
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 module
Terry Moore wrote:
> Just to clarify a bit
>
> > Indeed, we started with Lua because AWK was not embeddable and because of
> > the 1-origin issue.
>
> We thought, mistakenly, that a language that didn't look very much like C
> would cause fewer problems because of the 0-origin / 1-origin dif
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
> ...
>
I would like to manually fsck a filesystem which is currently NFS exported.
I could stop NFS, but that would affect several other file systems, too.
Is there a sane and safe way to handle this, i.e. resulting in being able to
fsck while NFS clients just hang with "NFS server not responding" for th
> Can there be some weird file system inconsistency fsck doesn't spot?
Yes. Well, almost certainly. When I was writing the program that
became resize_ffs when it was imported into NetBSD, I had a bug which
led to the kernel panicking when using the resized filesystem. jtk
found it - but the rel
On Sat, 19 Oct 2013 15:49:06 +0200, Edgar Fuß wrote:
> I would like to manually fsck a filesystem which is currently NFS exported.
> I could stop NFS, but that would affect several other file systems, too.
> Is there a sane and safe way to handle this, i.e. resulting in being
> able to fsck while
> I'd suggest poking around the oddities with fsdb or some such userland
> tool.
I'll try that.
> I'd also have suggested using clri (and then fsck) rather than
> rmdir to deal with the other directory, but that's water under the
> bridge now. (rmdir writes to places other than the directory bein
> Removing the share from /etc/exports and HUPing mountd(8) only helps for
> new mount requests, not existing mounts.
What would happen to NFS clients in case I stop nfsd, remove the partition
from /etc/exports and unmount it, then reload mountd and restart nfsd?
Strictly speaking, this is not a NetBSD kernel issue.
However, I hope that someone more familiar with mpt(4) has come accross that
MPT "feature" before:
One additional oddity I faced with Thursday's disc failure was that after
physically replacing the failed disc with a spare, the SAS controller
On Sat, 19 Oct 2013 17:56:02 +0200, Edgar Fuß wrote:
>> Removing the share from /etc/exports and HUPing mountd(8) only helps for
>> new mount requests, not existing mounts.
>
> What would happen to NFS clients in case I stop nfsd, remove the partition
> from /etc/exports and unmount it, then relo
On Sat, Oct 19, 2013 at 05:56:02PM +0200, Edgar Fuß wrote:
> > Removing the share from /etc/exports and HUPing mountd(8) only helps for
> > new mount requests, not existing mounts.
> What would happen to NFS clients in case I stop nfsd, remove the partition
> from /etc/exports and unmount it, the
> I'm getting two "Bad file descriptor" errors, one on a directory and
> another on a regular file, both in the same directory. What do you
> suggest to do?
Hm.
What do you get those errors from? find(1)? I think the first thing
I'd try to do is provoke them deliberately by hand - eg, try usin
On Sat, 19 Oct 2013 19:30:36 +0200, Manuel Bouyer wrote:
> On Sat, Oct 19, 2013 at 05:56:02PM +0200, Edgar Fuß wrote:
>> What would happen to NFS clients in case I stop nfsd, remove the partition
>> from /etc/exports and unmount it, then reload mountd and restart nfsd?
>
> The clients tries to ac
EF> What would happen to NFS clients in case I stop nfsd, remove the partition
EF> from /etc/exports and unmount it, then reload mountd and restart nfsd?
MB> The clients tries to access the parition you removed from exports will
MB> get a permission denied, or stale nfs file handle error.
OK, than
> What do you get those errors from? find(1)?
Yes.
What I've found out so far (from using fsdb) is that those two directory
entries (one directory and one regular file) point to unallocated inodes.
On Sat, Oct 19, 2013 at 09:21:13PM +0200, Hauke Fath wrote:
> On Sat, 19 Oct 2013 19:30:36 +0200, Manuel Bouyer wrote:
> > On Sat, Oct 19, 2013 at 05:56:02PM +0200, Edgar Fuß wrote:
> >> What would happen to NFS clients in case I stop nfsd, remove the partition
> >> from /etc/exports and unmount i
On Sat, 19 Oct 2013 22:01:41 +0200, Manuel Bouyer wrote:
>> How does [nfsd] learn about the content of exports(5)?
>
> from mountd. Mountd not only handle RPC requests, it also pass the export
> list to the in-kernel nfsd.
Ah, thanks - I missed that bit of information.
hauke
--
Hauke Fath
>> What do you get those errors from? find(1)?
> Yes.
> What I've found out so far (from using fsdb) is that those two
> directory entries (one directory and one regular file) point to
> unallocated inodes.
Okay, that's weird. fsck should have caught that - indeed, that's what
you'll see if yo
> Has the place you're getting the odd EBADF errors been created after
> you deleted the former mystery?
Probably yes (fsdb didn't give me the birth time, but ctime and mtime are
identical and later than the last fsck/deletion of the missing-dot/dotdot
dirctory.
> I'm wondering if perhaps it got
>> I'm wondering if perhaps it got the same inode or the same disk
>> block or some such.
> No. The directory that twice caused a panic because of missing
> dot/dotdot was inode 463357837, the one with the two entries pointing
> to unallocated inodes is inode 158304666, the two unallocated inodes
hi folks.
as part of the GCC 4.8 preparation work, we're seeing many new
warnings where variables are only used inside KASSERT(), but
the non-diag kernel builds trigger errors.
my solution, rather than marking these variables with __USE(),
is to change KASSERT() into a real function that consum
> If your filesystem uses 256K or larger blocks,
> those two inodes fall into the same block;
No, it uses 16k blocks.
31 matches
Mail list logo
