[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD/zaurus 8.1 problems and possible fixes
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
> 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.
Main Index |
Thread Index |