remove CHUNK_BSD_COMPAT, it was a bad idea, and now its gone.
remove DOSPTYP_ONTRACK, missed in OnTrack removal commit.
unifdef -DHAVE_GEOM
make tst01 compile again.
Constify some things.
Staticize some things.
Remove some unused things.
Prototype some things.
Don't install a gazillion man-pages links.
Drop support for ON-TRACK disk-manager.
o fillin media s/h/c fields from new XML phk just added; need this because
sysinstall uses them in the fdisk look-alike
o add new tags to xml parser
o cleanup parser a touch; remove unused tags and move tag parsing stuff to
a table to simplify future additions
o redo callback to pass 64-bit values since mediasize overflows u_int32_t
o loosen parsing sanity checks a touch to deal with new xml we must handle
o move sector size probing to non-geom handling since we now get it from xml
o remove WHOLE_DISK_SLICE buggery now that we get mediasize from xml
get the xml configuration for the devices and "parse" the information to
get what's needed
o replace #ifdef DEBUG constructs with DPRINT/DPRINTX to make the code more
readable
Note the xml "parser" is very very hackish and should be replaced with a
real one. This one was done to be very small and special-purpose; don't
think about copying it elsewhere.
Approved by: phk
o memory wasn't reclaimed in certain cases
o add more msgs under #ifdef DEBUG
o rewrite tangle of for loops for clarity
NB: Open_Disk should redo how it malloc's memory so the caller can free
everything. Documentation says the caller can free the disk list to
reclaim everything but this leaks the indirect strings. Fixing this
is simple for the sysctl case but adds complexity to the fallback,
non-sysctl, case.
Peter had repocopied sys/disklabel.h to sys/diskpc98.h and sys/diskmbr.h.
These two new copies are still intact copies of disklabel.h and
therefore protected by #ifndef _SYS_DISKLABEL_H_ so #including them
in programs which already include <sys.disklabel.h> is currently a
no-op.
This commit adds a number of such #includes.
Once I have verified that I have fixed all the places which need fixing,
I will commit the updated versions of the three #include files.
Sponsored by: DARPA & NAI Labs.
argument. Leave a compatibility shim for Delete_Chunk().
Implement DELCHUNK_RECOVER flag so sysinstall can ask libdisk
to recover space when deleting a chunk.
sysinstall will automatically expand the previous partition to take up
the freed up space. So you can 'D'elete /home and /usr will get the
combined space, or you can 'D'elete /tmp and /var will get the combined space.
This gives the user, developer, or lay person a huge amount of flexibility
in constructing partitions from an 'A'uto base. It takes only 3 or 4
keystrokes to achieve virtually any combination of having or not having
a /tmp and/or /home after doing an 'A'uto create.
Change 'A'uto creation of /var/tmp to 'A'uto creation /tmp, which should
be less controversial.
MFC after: 6 days
if and only if a target directory is devfs. Previous patch
doesn't correct, it's unconditionally avoid to create a device
file if kernel knows devfs.
PR: 31109
+ make Open_Disk sense the sector size by trying 512, 1024 and 2048
in this order. This makes the kernel note that
dscheck(cd1): bio_bcount 512 is not on a sector boundary (ssize 2048)
dscheck(cd1): bio_bcount 1024 is not on a sector boundary (ssize 2048)
if 2048 is the sector size. If this worries anyone: the message is from
/usr/src/sys/kern/subr_diskslice.c and shutups are to be placed there.
+ Have read_block and write_block use an additional parameter, the
sector size.
+ replace all barfout calls with return NULL, 0, __LINE__, etc.
Note that this does NOT emit diagnostics. More often than not,
you don't want library functions to scribble on stderr -- it may
not even be available. The right thing is to propagate the error
condition to upper management. The app should take care of errors.
+ use d1->sector_size instead of 512 in various places. I've left many
places untouched, especially those writing MBRs. I simply added
another arg hardcoded as 512. This is because I would not know what
I'm doing... I felt this approach would be reasonably backward
compatible and not introduce any new bugs in critical software.
Famous last words. Messing with MBRs might soon put me in the same
screwup meister category as, uh, never mind. :-)
+ bump the max no of disks from 20 to 32 (due to PR 24503).
PR: 8434 / 8436 / 24503
Submitted by: Jens Schweikhardt <schweikh@schweikhardt.net>
Also, looking to the future, don't assume all the world is an i386 and all
its disk layout brain damage will be repeated by other platforms. So all
the diking out if we are an Alpha, becomes adding in if we are an i386.