[parted-devel] probing devices.. some questions/comments
leslie.polzer at gmx.net
leslie.polzer at gmx.net
Sat Sep 9 10:57:35 UTC 2006
On Sat, Sep 09, 2006 at 09:39:41AM +0200, Bart Hakvoort wrote:
> lately i've been looking a bit into 'static void linux_probe_all()'
> (arch/linux.c around line 1614)
> Although very secure, this method creates some problems every now
> and then with bad dvd/cd(drive)'s. Large timeouts or even iolocked
> machines. Of course issues like this should eventually be solved by
> the user, but i'm not certain if we need to probe for these devices.
A patch to skip CD-ROM and floppy drives is currently on the way.
> The reason for probing these standard devices is in the source: /*
> we should probe the standard devs too, even with /proc/partitions, *
> because /proc/partitions might return devfs stuff, and we might not *
> have devfs available */
> Is this still valid? how many people still use devfs? However, i might
> be mistaken about the number of users who still rely on this :)
Yes, you are :)
> the reason for parsing the contents of /sys/block/ is: /* /sys/block
> is more reliable and consistent; fall back to using * /proc/partitions
> if the former is unavailable, however. */
> In what aspect is /sys/block more reliable and consistent?
> /proc/partition seems pretty complete to me :)
All I know is that /sys/block contains a lot more information.
Do you have problems with this two-fold approach?
> one last thingy about 'static int _probe_proc_partitions()'
> (arch/linux.c around line 1500). it says: /* Heuristic for telling
> partitions and devices apart * Probably needs to be improved */ Why
> not simply take the line with the lowest minor number? afaik this will
> always be the device.
Since the device doesn't have any number, I suppose you mean "no number"
by "lowest minor number". Isn't this what is currently being done?
The _match_rd_device() check is also necessary for devices like
as outlined in the justification comments before this function.
> btw, i realize all these things are quite trivial, but this has been
> popping in and out of my conciousness for over a year now :^)
Nice you finally managed to speak up! :)
> Also i'm happy to provide patches if necessary.
That's always good, of course. I'd appreciate it, however, if you'd
tell us more about the problems you have with the current approaches.
All the best,
gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/parted-devel/attachments/20060909/05dd9c77/attachment.pgp
More information about the parted-devel