On Fri, 2009-06-19 at 13:49 +0200, Joel Granados wrote: > Hello list. > > There was a discussion in irc about device filtering. I just wanted to > summarize and post what was discussed so we can maybe get some valuable > insight from the mailing list. > This is more like an irc dump than a summary. But I hope it shows some > of the topics that should/could be discussed This is very late, I know. Here is my take after an irc discussion with clumens. > > * 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 > - Specify with a checkbox if you want anaconda to use the regular > expression. > - Specify what that regular expression should do (Ignore or Include) I think the regex approach is way more than we can (or want to) chew for F12. It also sounds really unwieldy for users. Here's my proposal: a list of disks, each with a checkbox. The list items' information can be argued between device node name, size, model, whatever. We also provide a "select all" and "select none" button so users with 10,000 LUNs can hit "select none" and then click on their one local disk and proceed. It has been pointed out that we still want a way to specify devices in kickstart that does not rely on device node names. I think the sysfs path stuff can be useful here. Perhaps the identifiers used for /dev/disk/by-id and /dev/disk/by-path. I also keep thinking of checkboxes (which translate to switches in ks) like "select FCoE devices" or "select USB devices". > * Three possible scanning stages where identified. Each of these might > be controlled by the filter. > 1. Kernel scan I think we need to accept that this will have already happened by the time we have launched the graphical installer. Perhaps a separate mechanism can be developed to control this from the kernel command line? Maybe I'm just not familiar with the argument for needing this level of control, but to me it seems unnecessary. > 2. udev scan > 3. devicetree.py:scan To me it breaks down like this: 1. get a list of disks from udev 2. present the list, allow users to edit it 3. once the list is decided upon, do the full device scan and populate the tree I'm not sure where setup of isci/fcoe/zfcp devices fits into this but, given the matter of upgrades, it might be worth considering moving the entire storage configuration process ahead of the install/upgrade screen. > > * We actually want to be able to tell the kernel not to scan certain > LUN's. Why? Please do provide any feedback that occurs to you so we can continue to move this forward. Dave _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
