I decided to work on the md(4) driver and integrate the vn(4)
functionality into it mainly based on the name being more suitable.
Ideally 'vd' as in "virtual disk" would probably be the most logical
but our sound-master pointed out that this would cause uncontrollable
fits of giggles in the brits. Another complication would the needed
changes to the ramdisk boot/root functionality.
The vn driver will stay around for some time after I complete this
merge for transition reasons, and I'll make it whine to people that
they should migrate to the md(4) driver for some time before it
dies.
The kernel part of the new md(4) driver will be committed after more
testing.
so I am backing it out for now. The problem is that some random program
calling crypt() could be passing a DES salt and the crypt(3) library
would encrypt it in md5 mode and there would be a password mismatch as a
result. I wrote a validater function for the DES code to verify that
a salt is valid for DES, but I realized there were too many strange things
to go wrong. passwd(1), pw(8) etc still generate md5 passwords by default
for /etc/master.passwd, so this is almost academic. It is a big deal for
things that have their own crypt(3)-ed password strings (.htaccess,
etc etc). Those are the things I do not want to break.
My DES salt recognizer basically checked if the salt was either 2 or
13 characters long, or began with '_' (_PASSWORD_EFMT1). I think it
would have worked but I have seen way too much crypt() mishandling
in the past.
one-way hash functions for authentication purposes. There is no more
"set the libcrypt->libXXXcrypt" nightmare.
- Undo the libmd.so hack, use -D to hide the md5c.c internals.
- Remove the symlink hacks in release/Makefile
- the algorthm is set by set_crypt_format() as before. If this is
not called, it tries to heuristically figure out the hash format, and
if all else fails, it uses the optional auth.conf entry to chose the
overall default hash.
- Since source has non-hidden crypto in it there may be some issues with
having the source it in some countries, so preserve the "secure/*"
division. You can still build a des-free libcrypt library if you want
to badly enough. This should not be a problem in the US or exporting
from the US as freebsd.org had notified BXA some time ago. That makes
this stuff re-exportable by anyone.
- For consistancy, the default in absence of any other clues is md5. This
is to try and minimize POLA across buildworld where folk may suddenly
be activating des-crypt()-hash support. Since the des hash may not
always be present, it seemed sensible to make the stronger md5 algorithm
the default.
All things being equal, no functionality is lost.
Reviewed-by: jkh
(flame-proof suit on)
process. This fixes a problem when attaching to a process in gdb
and the process staying in the STOP'd state after quiting gdb.
This whole process seems a bit suspect, but this seems to work.
Reviewed by: peter
parallel fsck's one per drive, use the shortest prefix ending in
a digit rather than the longest prefix ending in a digit.
This makes "/dev/ad0s1a" and "/dev/ad0s2a" appear to both reside
on the disk "/dev/ad0" and consequently they will be fsck'ed
sequentially rather than in parallel as now.
In general this heuristic is rather soft and errorprone. For
instance ccd may often reside on two or more physical disks. A
good solution would be to look for passes larger than 1 until no
disks are found in a particular pass, that way people could put
ccd stripes in pass 3... and have them fsck'ed sequentially.
Reviewed by: mjacob
with the driver locking up under load.
- Restructure so that we use a static pool of commands/FIBs, rather than
allocating them in clusters. The cluster allocation just made things
more complicated, and allowed us to waste more memory in peak load
situations.
- Make queueing macros more like my other drivers. This adds queue stats
for free. Add some debugging to take advantage of this.
- Reimplement the periodic timeout scan. Kick the interrupt handler
and the start routine every scan as well, just to be safe. Track busy
commands properly.
- Bring resource cleanup into line with resource allocation. We should
now clean up correctly after a failed probe/unload/etc.
- Try to start new commands when old ones are completed. We weren't doing
this before, which could lead to deadlock when the controller was full.
- Don't try to build a new command if we have found a deferred command.
This could cause us to lose the deferred command.
- Use diskerr() to report I/O errors.
- Don't bail if the AdapterInfo structure is the wrong size. Some variation
seems to be normal. We need to improve our handing of 2.x firmware sets.
- Improve some comments in an attempt to try to make things clearer.
- Restructure to avoid some warnings.
when using gdb on a remote target. The fix is to restrict PT_GETDBREGS
calls to `child' and `freebsd-uthreads' targets solely.
I've been in some conversation with Brian about this, and this solution
seems to be the most appropriate one.
PR: gnu/21685
Submitted by: bsd
