> On Wed, May 04, 2011 at 08:50:10PM +0900, Izumi Tsutsui wrote:
> > The problem is that there might be some ports whose MAXPARTITIONS is still 8
> > and such ports can't use type 8.
>
> Why not? It is not used as a partiton of fd*.
> MAKEDEV is already wrong
The problem is that there might be some ports whose MAXPARTITIONS is still 8
and such ports can't use type 8.
---
Izumi Tsutsui
> > I.e. currently only root on cd0a works on x86 GENERIC anyway.
>
> One more bug to fix, but unrelated to this thread, isn't it?
> See also PR 43012.
I thought passing "root on cd0a" from boot.cfg just worked on x86..
---
Izumi Tsutsui
* XXX
>> * There is no proper way to detect which unit is
>> * recognized as a bootable CD-ROM drive by the BIOS.
>> * Assume the first unit is the one.
>> */
I.e. currently only root on cd0a works on x86 GENERIC anyway.
---
Izumi Tsutsui
yamt@ wrote:
> i'd like to remove the sparseness check in vnd because there's
> no problem to use a sparse files on nfs.
We really want vnd on sparse files for emulator images...
---
Izumi Tsutsui
x27;s worth to add a sysctl knob that returns
whether the running kernel has options COMPAT_386BSD_MBRPART or not
and make disklabel(8) refer it.
---
Izumi Tsutsui
s.
I think it's enough to bump a version number on possible
functional changes. Fewer changes on boot than kernels.
---
Izumi Tsutsui
cal ones)
and it isn't easy to log bootloader's strings without serial console,
which is uncommon for non-geek users.
---
Izumi Tsutsui
st ports can have such implementation,
I think (though it's still imaginary). No idea what will modules_enabled
help for us.
---
Izumi Tsutsui
d down userland.
We have to move boot.cfg(5) support and loading module functions
from i386/stand to MI libsa, I think.
---
Izumi Tsutsui
boot.cfg.in in netbsd-5.
(-current doesn't use miniroot.kmod and use cd9660 root fs)
Modules loaded by the bootloader are handled in module_init_md()
as x86/x86_machdep.c inside #ifdef MODULAR so if the kernel
doesn't have MODULAR I think loaded modules are simply ignored.
--
Izumi Tsutsui
(as sys/arch/i386/stand/lib/exec.c:command_load_kernel() does),
not the root file system. (they are identical in most case though)
Necessary info is "if the loaded kernel has modules for the file system."
---
Izumi Tsutsui
r modules can be loaded
from the root file system after mountroot().
So necessary info might be "which file-system modules are builtin?"
(though I'm not sure if options NFS_BOOT_DHCP requires bpf(4) module or not)
---
Izumi Tsutsui
extra support for bus controller
that supports byteswap ops, not individual bus masters.
---
Izumi Tsutsui
> Also, there is a comment above saying that:
>
> /*
> * The following data structures are generated from RTL code.
> * Do not modify any values below this line.
> */
IMO all members fetched via PCI bus master should be uint32_t
if hardware supports byte swap ops since swap is always done
> I have ported various modifications from OpenBSD and FreeBSD to bnx(4)
> and brgphy(4) (see attach).
:
> --- sys/dev/mii/brgphy.c 27 Nov 2010 17:42:04 - 1.56
> +++ sys/dev/mii/brgphy.c 30 Nov 2010 23:58:49 -
:
> #include
> -#if 0
> #include
> -#endif
:
> +
_phys_address(paddr_t cookie)
:
>> The existence of this function is highly dubious, and it is
>> expected that this function will be removed from the pmap
>> API in a future release of NetBSD.
---
Izumi Tsutsui
l just make NetBSD rotten.
---
Izumi Tsutsui
. I'm just a user, what do you need with us? We're an
> impediment.
Just use your favorite ports and report problems you find,
but please don't complain if they are unusable or even EOLed
due to lack of resources etc.
---
Izumi Tsutsui
machines with MI API.
> > It's bad thing to complain about MI API to keep support for old machines.
>
> If the API isn't really MI anymore, is it still not ok to complain about?
If there is no reasonable alternative, it means EOL of that machine,
as 80386.
---
Izumi Tsutsui
o complain about MI API to keep support for old machines.
> Ha! Have you tried using it, or are you satisfied it passes
> cross-compilation?
Works on TME. Anyone can confirm it.
---
Izumi Tsutsui
rn applications"
and users should choose machines per their requirements. That's all.
> bqt, wanna start a fork? Looks as though NetBSD no longer supports
> most of the architectures it used to.
NetBSD/sun2 5.1 still works on multiuser (though gcc won't work on it).
It shows scalability of NetBSD, and it's enough for me.
---
Izumi Tsutsui
> What are the flaws?
You have not answered all questions and no one says go ahead.
---
Izumi Tsutsui
> I have answered all questions from Chuck.
Does he say go ahead?
> Tsutsui-san doesn't need to understand XIP.
I don't understand most your description.
If Core does, I'll shut up.
---
Izumi tsutsui
asked you first?
He said pmap_extract() could be used to get PA from VA.
You just answered pmap_extract() was bad API.
What you were trying to solve?
If existing API can solve it without bad side effect,
I don't think it's so bad for your purpose and
its design should be another discussion.
---
Izumi Tsutsui
ts
etc.
> I asked Chuck Silvers to review the branch. I believe I've addressed
> most of his questions except a few ones.
It's also better to post all his questions and your answers
so that other guys can also see what's going on.
---
Izumi Tsutsui
if (securelevel > 0)
+ if ((uintptr_t)arg2 == 0 && securelevel > 0)
result = KAUTH_RESULT_DENY;
break;
---
Izumi Tsutsui
the author of the autoloading
> code; the system scope kauth listener should return DEFER, not DENY.
Okay, fair enough. Thanks.
> However, I think it's a troublesome question whether this is really
> the right policy to apply.
:
Well, it's another discussion how modules can be secure,
which is out of my scope.
---
Izumi Tsutsui
is required to use module/autoloading
because some ports require it.
---
Izumi Tsutsui
said *every* port?
> > > > If we should I'll enable options INSECURE by default on ports
> > > > that require options MODULAR (to save kernel file size).
I'm just asking if "options INSECURE is mandaory to use autoloading,"
not module/autoloading is secure/silly/boo or not.
---
Izumi Tsutsui
ur own convenience.
> >
> > Heh, then why have we had it on i386 for years?
>
> Because of the X server.
You are just saying:
"We introduced a significant security regression just for our own convenience."
I see no proper reason to avoid INSECURE for MODULAR if it's okay for X.
---
Izumi Tsutsui
> > If we should I'll enable options INSECURE by default on ports
> > that require options MODULAR (to save kernel file size).
>
> Do not do that. You will introduce a significant security regression
> just for your own convenience.
Heh, then why have we had it on
# mount -t tmpfs tmpfs /mnt
DEBUG: module: plist load returned error 2 for
`/stand/sun3/5.99.39/modules/tmpfs/tmpfs.kmod'
chariot# df /mnt
Filesystem 1K-blocks Used Avail %Cap Mounted on
tmpfs 49480 8 49472 0% /mnt
# DEBUG: module: cannot unload module `tmpfs' error=16
---
Izumi Tsutsui
e a.out binaries on multiuser
though they worked after shutdown(8) or on single user.
The code doesn't work as intended and just we should fix it?
---
Izumi Tsutsui
think the point is whether we should require INSECURE or not
to use module autoload/autounload after multiuser.
If we should I'll enable options INSECURE by default on ports
that require options MODULAR (to save kernel file size).
---
Izumi Tsutsui
s where you want to lock it.
When can we lock the state for pseudo devices (vnd, bpf etc) and
all hot plug devices? Extra file-systems and exec formats could
also be invoked after multi user.
Do we have to predict all possible necessary modules as a kernel config?
---
Izumi Tsutsui
> revision 1.26
>> date: 2008/11/14 23:06:45; author: ad; state: Exp; lines: +85 -3
>> - If the system encounters a severe memory shortage, start unloading
>> unused kernel modules.
>> - Try to unload any autoloaded kernel modules 10 seconds after their
>> load was successful.
---
Izumi Tsutsui
t just works,
> > but is it intended feature?
>
> It would seem to be intentional. After all, kernel modules can
> do all sorts of nasty things if they want to.
In that case, module autoload/autounload is not functional at all and
we have to specify all possible necessary modules explicitly
during boot time??
---
Izumi Tsutsui
options INSECURE is specified.
i386 has options INSECURE by default so it just works,
but is it intended feature?
---
Izumi Tsutsui
ame message
> is len=-1.
I'm afraid it's memory corruption caused by hardware or PCI BIOS problem.
What happens if you change
> cfg = RE_CPLUSCMD_PCI_MRW;
to
> cfg = 0;
in re_init()? Or can you have newer BIOS for your hardware?
That's the only change that affects xfers in rev 1.105.4.8 and 1.72.2.11.
---
Izumi Tsutsui
> > Should I do commit this patch?
>
> yes please!
Committed. Thanks,
---
Izumi Tsutsui
he
> other with local framebuffer console / wscons. I net-booted the machine
> to single user mode only.
Should I do commit this patch?
---
Izumi Tsutsui
because firmware files should be in the root file system (in /libdata)
> as well as kernel module binaries.
>
> If there is no particular objection to concept of config_mountroot(9)
> itself, I'll commit this patch in a few days.
---
Izumi Tsutsui
include/z8530var.h 20 Jun 2010 01:58:29 -
@@ -54,6 +54,7 @@
int zsc_node; /* PROM node, if any */
struct evcntzsc_intrcnt;/* count interrupts */
struct zs_chanstate zsc_cs_store[2];
+ void*zsc_sicookie; /* softint(9) cookie */
};
/*
---
Izumi Tsutsui
rrupts
by sharing one interrupt handler among all zs devices.
We can simpley fix it to make it call softint_establish() and
bus_intr_establish() per each zs device, as macppc and news68k etc. do.
---
Izumi Tsutsui
we should
rather control device attachment by drvctl(8) to defer it during rc(8),
but I think we should handle such mechanizm in different layer
because firmware files should be in the root file system (in /libdata)
as well as kernel module binaries.
If there is no particular objection to concept of config_mountroot(9)
itself, I'll commit this patch in a few days.
---
Izumi Tsutsui
ountroot().
I've posted a patch for this into PR kern/43125:
http://mail-index.NetBSD.org/netbsd-bugs/2010/06/13/msg018111.html
---
Izumi Tsutsui
d.
I think it can be implemented as well as config_interrupt().
You can register all deferred initializetions via config_mountroot()
(or so) like config_interrupt() and they could be established by
config_finalize_mountroot() (or so) from init_main.c after mountroot().
---
Izumi Tsutsui
http://mail-index.NetBSD.org/tech-kern/2010/05/27/msg008240.html
* Do you seriously consider whether you can also apply your API
changes to sparc and all other ports that have more complicated
bus_space_tag_t internal structures?
As I and Eduardo wrote x86's bus_space_tag_t is too simple
to abstruct API. It's hard to review x86's sample code without
examples of usage of new APIs.
---
Izumi Tsutsui
e "create tag"?
IMO "refine" is also too vague. It should imply what actually
the function does, i.e just adding MI hooks.
(no actual implementation in your patch so I can't comment)
---
Izumi Tsutsui
here is no defined API to specify
various MD implementation (map/access, stride/byteswap/wordoffset etc.)
in MI bus_space_tag_create().
---
Izumi Tsutsui
> I am not sure that I understand your question.
Could you answer my first message?
http://mail-index.NetBSD.org/tech-kern/2010/05/27/msg008240.html
---
Izumi Tsutsui
> You could use bus_space_tag_create() in MD code such as if_ne_mb.c and
> dev/sbus/stp4020.c, but I don't know if it will be worth it. The code
> would look more consistent with MI code.
How can you switch multiple MD bus_space_tag_t types in MI API?
---
Izumi Tsutsui
n MD implementation.
(See atari/dev/if_ne_mb.c for awful examples)
---
Izumi Tsutsui
(See mips/include/bus_space.h, powerpc/include/bus.h,
atari/atari/mainbus.c etc.)
On such ports, the name of "bus_space_tag_create()" looks a bit confusing.
I think the new functions should imply "adding/removing MI hooks
to/from MD bus_space_tag_t provided by MD implementation,"
not creating/destroying tags.
---
Izumi Tsutsui
p the parts already done by the first if it ran already).
Some fb drivers (dev/pci/tga.c, dev/tc/sfb.c etc) have
a structure for rasops in softc.
For console it's statically allocated and initialized via consinit.
For non-console, it's allocated by malloc(9) and initialized
during device autoconf.
---
Izumi Tsutsui
sider about bus_space(9))
- complicated framebuffer with large memory
- and others? (arc and ews4800mips set up wired map for framebuffer)
---
Izumi Tsutsui
tup()
sys/arch/arc/arc/bus_space.c:arc_bus_space_extent_malloc_flag()
etc.
I have no idea if we should have a more generic flag.
---
Izumi Tsutsui
region to be managed by VM. When user process maps these regions, VM will
> take care of detailed treatment.
What's different from bus_space_alloc(9)?
Even if there is some API difference,
doesn't it require more parameters as bus_space_alloc(9)?
---
Izumi Tsutsui
s are required.
IMO, "tier"ing ports might be better for us than "best or die" scheme.
In that case you can leave unused ports and devices in dead state.
---
Izumi Tsutsui
ptions, resouce management
for bus_space(9) and bus_dma(9) too?
---
Izumi Tsutsui
not GENERIC.MP), or netbsd-5?
---
Izumi Tsutsui
de
-#include
-#include
-
#include
#include
@@ -142,21 +139,10 @@
case NE2000_TYPE_NE2000:
typestr = "NE2000";
- /*
- * Check for a Realtek 8019.
-*/
- bus_space_write_1(nict, nich, ED_P0_CR,
- ED_CR_PAGE_0 | ED_CR_STP);
- if (bus_space_read_1(nict, nich, NERTL_RTL0_8019ID0) ==
- RTL0_8019ID0 &&
- bus_space_read_1(nict, nich, NERTL_RTL0_8019ID1) ==
- RTL0_8019ID1) {
- typestr = "NE2000 (RTL8019)";
- dsc->sc_mediachange = rtl80x9_mediachange;
- dsc->sc_mediastatus = rtl80x9_mediastatus;
- dsc->init_card = rtl80x9_init_card;
- dsc->sc_media_init = rtl80x9_media_init;
- }
+ break;
+
+ case NE2000_TYPE_RTL8019:
+ typestr = "NE2000 (RTL8019)";
break;
default:
---
Izumi Tsutsui
> On Fri, Feb 26, 2010 at 08:15:39AM +0900, Izumi Tsutsui wrote:
> > > in the same way there are ABI differences between
> > > atari and mac68k.
> >
> > What are actually differnt between them?
>
> bus_space_handle_t is different, for example.
> I&#x
> in the same way there are ABI differences between
> atari and mac68k.
What are actually differnt between them?
---
Izumi Tsutsui
But, I agree it's better to make paddr_t always 64 bit,
if there is no ABI issue on the transition.
---
Izumi Tsutsui
> Please commit.
Sorry but if you think it's necessary for your goal please commit it yourself.
---
Izumi Tsutsui
you have a certain plan how to fix rest of bugs,
but it might be better to have some review before proceeding.
Actaully it would not look so difficult to fix them, but
I wonder if we should have some proper names which explicitly
describe physical or logical blocks because passing logical
block nu
;cleaning up old code"?
Don't they require physical blocksize value stored in superblock?
---
Izumi Tsutsui
erblock" means
and it's independent from raw I/O size in kernel.
Why do you leave fsbtodb() to use fs_fsbtodb for userland?
To have less changes?
---
Izumi Tsutsui
at's the consisntent definition?
As I wrote before, we also have to consider about DIRBLKSIZ value.
---
Izumi Tsutsui
ommand.
(if you need hardware I can send the drive and media..)
> N.B. newfs doesn't yet know how to deduce sector sizes, you need
> to use the -S option.
newfs(8) doesn't work even with -S 2048 option.
(probably it tries to write data at offset not sectorsize aligned)
---
Izumi Tsutsui
).
fdisk(8) should know hardware sector size anyway.
Otherwize it can't calculate LBA in the sector size
from partition size in MB or GB.
---
Izumi Tsutsui
have the same issue.
>
> lfs is obvious (same code as ufs). I haven't looked at ext2fs.
ext2fs itself doesn't have fsbtodb member in superblock.
But our implementation prepare it in struct m_ext2fs to share
structures among other ufs code, and ext2fs_vfsops.c says
"XXX assume hw bsize = 512". Oh well.
---
Izumi Tsutsui
|
0820 4f bc 04 00 00 00 29 dc a5 88 cc 4e 4f 20 4e 41 |O.)NO NA|
0830 4d 45 20 20 20 20 46 41 54 31 36 20 20 20 33 c9 |MEFAT16 3.|
---
Izumi Tsutsui
51.53MB, 9698 blks, 19072 inodes.
wtfs: write error for sector 310332: Invalid argument
# newfs -S 2048 -I /dev/rdk0
/dev/rdk0: 606.1MB (310333 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 151.53MB, 9698 blks, 19072 inodes.
wtfs: write error for sector 310332: Invalid argument
#
---
Izumi Tsutsui
EV_BSIZE for sizes.
Isn't it one example of inconsistent hacks?
There is no "right" solution. We can fix the hack with hacks,
or we can also redesign it. Someone[tm] should make a decision.
That's all.
---
Izumi Tsutsui
s_msdos(8) and mount_msdos(8) work)
IMO current blkno translations in wd(4) and sd(4) are just
a hack without consideration to buffercache(9).
---
Izumi Tsutsui
alculated by fsbtodb to buffercache(9).
IMO, such "less necessary changes" will include much more logical hacks
which will confuse future developers, as current inconsistent implementation.
I wonder if 512bytes/sector will become legacy or not in future..
---
Izumi Tsutsui
Jason Thorpe wrote:
> On Jan 13, 2010, at 3:57 AM, Izumi Tsutsui wrote:
>
> > As I wrote first, we should make a decision of buffercache(9)
> > and physio(9) APIs for !512bytes/sector disks.
> > Fixing file systems or disk drivers without it just generates
> > ye
da...@l8s.co.uk wrote:
> On Tue, Jan 12, 2010 at 10:48:04PM +0900, Izumi Tsutsui wrote:
> > In traditional implementation, DEV_BSIZE means minimum I/O size of
> > hardware devices, and it's always same as hardware sector size.
> >
> > To support >512by
to bother to support it.
(though it might be trivial once we abandon traditional DEV_BSIZE
constant from raw I/O access and all scsipi drivers)
---
Izumi Tsutsui
assumption that unit of I/O size is constant.
(i.e. no generic way to get actual I/O (== sector) size)
We have to consider about tradeoff, but I'm afraid
it's too dificult to choose one of them.
---
Izumi Tsutsui
101 - 183 of 183 matches
Mail list logo
