Le 12/07/2014 00:42, Paul Goyette a écrit :
I run without _any_ EXEC_* or COMPAT_* module compiled into my kernel. ALL of
my EXEC_* and COMPAT_* modules are auto-loaded as needed from the file system.
Please don't break this! :)
Well, netbsd32 already breaks the module loader, because of a
A long time ago (in pine.neb.4.64.1002090351150.23...@mail.netbsd.org)
you wrote:
I do disable fsck_lfs. It usually causes more problems than it
solves. It needs a complete overhaul. It tries to act like
fsck_ffs instead of validating segment checksums and regenerating
the ifile.
A
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 advance!
--
0007:
lua: updated from 5.1 to 5.3 work3
* lua(1):
- changed lua_Integer to intmax_t
- updated
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 advance!
--
0007:
lua: updated from 5.1 to 5.3 work3
I will review the changes later but I wonder
Hi Alexander,
On Sat, Jul 12, 2014 at 5:01 PM, Alexander Nasonov al...@yandex.ru 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 advance!
--
0007:
I'm sure it does need a complete overhaul. What I did with fsck_lfs was
essentially to adapt the parts of fsck_ffs that check what is common to
the two FSs (directories, inodes, block addresses, sizes, etc.) to LFS's
way of locating inodes, as well as the additional constraint that blocks
hi folks.
something really nasty happens on drmkms kernels if the vesa xorg
driver is loaded. they're not compatible and won't become that way.
the way xf86-video-vesa handles this is by a libpciaccess call to
determine if the device has a kernel driver attached. i've implemented
this below
