On Tue, Nov 17, 2015 at 8:56 AM, Jerry Hoemann <jerry.hoemann@xxxxxxx> wrote: > On Mon, Nov 16, 2015 at 05:29:41PM -0800, Dan Williams wrote: >> On Mon, Nov 16, 2015 at 1:10 PM, Jerry Hoemann <jerry.hoemann@xxxxxxx> wrote: >> > On Mon, Nov 16, 2015 at 11:00:20AM -0800, Dan Williams wrote: >> >> On Mon, Nov 16, 2015 at 10:38 AM, Jerry Hoemann <jerry.hoemann@xxxxxxx> wrote: >> >> > >> >> > > ... > >> >> Let's not do the _intel vs _passthru split. I want to convert the >> >> existing commands over to this new interface and deprecate the old >> >> ioctl-command formats. I.e. it isn't the case that this will be a >> >> always be a blind "passthru" mechanism, the kernel will need to crack >> >> open this payload in some circumstances. >> > >> > >> > I'm confused. >> > >> > In this version there is only 1 ioctl 'N'. The pass thru is using >> > number 100. This is what I thought you wanted from prior comments. >> >> It is indeed, I like that change. >> >> > The split are for internal functions that deal specifically w/ >> > the argument marshaling code and copy-in/copy-out. These mechanisms >> > are different. >> > >> > I understand that you want to switch over, but don't you (at least for >> > the time being) need to keep the old marshaling code for the current >> > use case? I was assuming a sequence like: >> > 1. The pass thru code gets submitted. >> > 2. The current tools are converted over to using the pass thru, >> > 3. The marshaling code using nd_cmd_in_size etc., would then >> > be removed. >> > >> > Are you wanting to make one big change and not in separate steps? >> >> I want to do it in separate steps, I'd just like to see cmd number 100 >> added to the existing __nd_ioctl and acpi_nfit_ctl routines. That > > Why? Because there's no need for the intel vs passthru distinction, it's just yet another command. >> plus quibbling about the name "ND_CMD_PASSTHRU". Given the plans to >> eventually replace the existing commands we can call it something like >> 'ND_DSM_GENERIC'. > > > No problem. I'll change the name for ndn_passthru_pkg in a similar fashion. > > > Question: Are you planning to add other CMDs to the IOCTL in the future? > (eg. ones not directly related to calling _dsm?) > > Or, is the ultimate goal to have an IOCTL that supports > only the generic DSM call? I'm not ruling out the possibility that there may be a non-DSM command in the future, but I don't see any need for that on the horizon. Why would it matter? -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
