Can we resume this thread? I still have objections against an automated solution (see below) and would like to get a patch merged that makes "size" writable in sysfs. We should probably think of a way to inform the block layer more formally. On Thu, Dec 24, 2009 at 2:40 PM, Clemens Fruhwirth <clemens@xxxxxxxxxxxxx> wrote: > Hi Bartlomiej, Hi Grant! > > On Mon, Dec 21, 2009 at 10:59 PM, Bartlomiej Zolnierkiewicz > <bzolnier@xxxxxxxxx> wrote: >> >> We should be able to detect working SD reader/card combination in sd >> driver's ->set_capacity method implementation (i.e. by issuing read >> request for the last partitioned sector outside of the reported device >> capacity) during the initial partition table scan and at the same time >> adjust the device capacity used by the kernel if necessary. > > 1. I disagree with the strategy to add some automatism that does not > work for all cases (unformated cards in this case). Do you want the > user to jump through the additional hop of creating oversized > partition tables that fdisk and friends might not even allow easily? > The case with manual override is easier and more straight forward. > Also this approach is tied to using partition tables and in my case SD > cards work fine without partition tables. > > 2. I strongly opt for not-creating a kernel that tries to domineer[1] > over its users. If I say my device is size X I want the kernel to > follow that order. Also I dislike the kernel to probe beyond the > device boundaries unless I told it do so. I don't want to be this > behavior to be auto enabled by (probably broken) partition tables that > I can not even see before plugging that disk into my device (and > naturally triggering this behavior) > > 3. The kernel is not supposed to work correctly when writing incorrect > junk to random sysfs files. So assuming the required knowledge for > manual intervention is ok at /sys. > >> Firstly block layer needs to be properly informed about capacity changes >> (set_capacity() + request for partition rescan which the patch doesn't do) >> and secondly fixing the problem at the sysfs block/partition layer seems >> to be a layering violation (i.e. it also allows partition size changes). > > git log -p --color db429e9^1..e957b60 does not seem related to me. The > implementation of ide_disk_set_capacity suggests that the semantic of > set_capacity is that the caller can make the device smaller than > probed_capacity with the intention to protect stuff (Host Protect > Area?). The caller can not enlarge the device beyond the device > boundaries because of its first line "u64 set = min(capacity, > drive->probed_capacity)". The intention of my patch and its potential > use of any set_capacity is exactly that, namely to override these > device limits. So it's seems a bit orthogonal. > > I don't object to inform the device layer somehow about the forceful > size change, however is set_capacity really the intended place to do > it? Where do we set nr_sects, if so? > > [1] Sorry if that translation sounds strange: > http://dict.leo.org/ende?search=bevormunden > -- > Fruhwirth Clemens http://clemens.endorphin.org > -- Fruhwirth Clemens http://clemens.endorphin.org -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
