Re: NetBSD/zaurus 8.1 problems and possible fixes

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

Sorry, I'm not sure what's your point.

I'm just pointing out that current MAKEDEV.awk has a dumb bug and
I guess it can easily be fixed by gurus because it's a host tool.
Changing RAW_PART for such an trivial bug looks like a sledge hammer
for me.

> fdisk, disklabel and friends should just work with a different
> RAW_PART kernel - as long as the partition-letter-less device points
> to the right dev

The problem here is MAKEDEV creates incorrect
partition-letter-less devices for such commands due to
the current MAKEDEV.awk implementation.

> or they are run with manually with the correct device
> letter specified.

Another problem is current opendisk(3) implementation is assuming
partition-letter-less device is always a "correct" raw device
if it exists (i.e. unless ENOENT) and there is no fallback to
trying device nodes with a partition-letter using getrawpartition(3).

It looks opendisk(3) was implemented to avoid userland programs
from specifying an explicit RAW_PART letter (but not sure).

> It sounds like a migration should be possible - but
> whether it is worth the effort is another question :)

Do you have any specific migration senario?
For example, how will on-disk existing disklabels be updated?

> Could the issue have been introduced by someone trying to move towards
> userland sharing for same cpu arch ports?

I thinks "userland sharing" and MAKEDEV issue is independent
unless /dev/MAKEDEV files are shared.

In the perfect world[TM], the right way to go is implementing devfs,
rather than complicated scripts, I guess.

---
Izumi Tsutsui