Just a few comments from the viewpoint of the s390 architecture, which could provide use cases since there are often many (hundreds or thousands of) devices, as we have already discussed at FUDCon. On 06/19/2009 01:49 PM, Joel Granados wrote: > * What information to give to the filter? This is related to the UI. > And this was the reason to begin the discussion. > - Give a regular expression that identifies the devices Regexes seem way too complicated for anaconda which otherwise guides the user in a very helpful way. Wouldn't two entry fields to specify an interval/range do it? I mean, on systems with many (hundreds to thousands on s390) devices users would typically want to filter for device number ranges. E.g. activate all DASDs between and including 0.0.beef and 0.0.dead. > * On what would those regular expressions operate? > - canonicalized path of the device link under /sys/block. > - []$ readlink -f /sys/block/sda/device > /sys/devices/pci0000:00/0000:00:05.0/host0/target0:0:0/0:0:0:0 # readlink -f /sys/block/dasda/device /sys/devices/css0/0.0.0003/0.0.eb1b # readlink -f /sys/block/sda/device /sys/devices/css0/0.0.0015/0.0.3c1b/host0/rport-0:0-24/target0:0:24/0:0:24:1089355792 > - /dev/disk/by-path version is also possible. Could be useful. /dev/disk/by-path/ccw-0.0.eb1b -> ../../dasda /dev/disk/by-path/ccw-0.0.3c1b-zfcp-0x5005XXXXXXXXXXXXX:0xXXXXXXXX00000000 -> ../../sda By-path looks less confusing but I don't know whether users would want to filter for rport, target or other stuff in the canonicalized path. > * Why not have the possibility to refresh? (Refresh would work with > the information contained in the kernel.) > - The user tweaks the scanning list and hits refresh. > - User does this until he/she is satisfied with the device list. > > * Three possible scanning stages where identified. Each of these might > be controlled by the filter. > 1. Kernel scan On s390 we have a kernel command line option cio_ignore to prevent devices from even being sensed by the kernel, since on systems with thousands of devices already the pure sensing might consume too much time or memory (for the allocated in-kernel device objects). > 2. udev scan > 3. devicetree.py:scan > > * We actually want to be able to tell the kernel not to scan certain > LUN's. > > * Wish people would learn how to configure fibrechannel switch acl's so we > would only see the lun's they actually want us to touch. Would it > be a good idea to document the configuration setup that anaconda > expects? On s390, only devices that have been sensed *and* are activated explicitly become visible to Linux. I agree with Chris that we should support all users no matter how they have configured their I/O subsystem. Even if users have setup their FCP storage network with ACLs but don't have NPIV in their hardware, they might see all disks of all virtual machines on the system. Due to massive virtualization this means n disks per VM times the number of VMs which might be hundreds and thus too many devices. Even if this might mean that s390 does not need additional device filtering, it maybe advantageous to design it such that we can share code between generic filtering and the display filtering of devices in the advanced storage configuration subdialogs. Steffen Maier Linux on System z Development IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Erich Baier Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
