On 11/12/13 at 12:30am, Greg KH wrote: > On Tue, Nov 12, 2013 at 04:08:54PM +0800, Dave Young wrote: > > On 11/11/13 at 11:58pm, Greg KH wrote: > > > > kexec-tools can have a fallback to debugfs if we really need it, but > > > > making people mount debugfs to have some essential piece of > > > > functionality scares the heck out of me. > > > > > > I agree, that would not be good. > > > > > > I'm not sure what exactly the sysfs file is wanting to look like? The > > > efi section variable sysfs file isn't ok (multiple lines with multiple > > > values.) What is this going to look like? > > > > The current structure in debugfs is like below, export every field of setup > > header as one file will be too much IMHO: > > [root@darkstar debug]# tree boot_params > > boot_params > > ├── data /* binary data of setup header */ > > ├── setup_data /* setup_data link list nodes */ > > │ ├── 0 > > │ │ ├── data /* binary data of setup data */ > > │ │ └── type /* type of setup data */ > > │ └── 1 > > │ ├── data > > │ └── type > > └── version /* boot protocol version */ > > And these binary data blobs are a "standard" somewhere, and will not > change per kernel version change? IMO the topology should be standard. The content could change, for example later bumping boot protocol version, we could add new field in setup header.. hpa should know more about this.. Peter could you answer this question? > > If so, that structure is fine with me. > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
