Il 26/01/2013 00:47, Tejun Heo ha scritto:
>> > If I make a whitelist with all the commands that Linux sends, I'll have
>> > many new commands in the whitelist and no old commands. The new
>> > commands didn't exist when old drives were sold, so they are "dangerous"
>> > in your opinion. At that
Il 26/01/2013 00:47, Tejun Heo ha scritto:
If I make a whitelist with all the commands that Linux sends, I'll have
many new commands in the whitelist and no old commands. The new
commands didn't exist when old drives were sold, so they are dangerous
in your opinion. At that point I might
Hello, Paolo.
On Sat, Jan 26, 2013 at 12:32:36AM +0100, Paolo Bonzini wrote:
> If I make a whitelist with all the commands that Linux sends, I'll have
> many new commands in the whitelist and no old commands. The new
> commands didn't exist when old drives were sold, so they are "dangerous"
> in
Il 25/01/2013 23:41, Tejun Heo ha scritto:
> Hello, Paolo.
>
> On Fri, Jan 25, 2013 at 11:32:42PM +0100, Paolo Bonzini wrote:
>> All you can do is use common sense, which says that if a command has
>> been in a standard, someone has likely used it. Of course someone
>> _might_ have misused it
Hello, Paolo.
On Fri, Jan 25, 2013 at 11:32:42PM +0100, Paolo Bonzini wrote:
> All you can do is use common sense, which says that if a command has
> been in a standard, someone has likely used it. Of course someone
> _might_ have misused it too, but how likely is that?
So, that's where we
Il 25/01/2013 20:01, Tejun Heo ha scritto:
> Some did that at least in ATA. It was mapping some command to
> firmware write. Given how many USB devices implement SCSI these days,
> I wouldn't be too firm with "that doesn't happen". How can such
> all-covering statement be asserted?
Of course
Hey,
On Fri, Jan 25, 2013 at 07:47:47PM +0100, Paolo Bonzini wrote:
> That doesn't happen. There's plenty of vendor-specific opcodes and mode
> pages, not to mention out-of-band channels, e.g. work directly at the
> USB level like the mode select stuff.
>
> IIRC IOMEGA ZIP drives had some
Il 25/01/2013 19:13, Tejun Heo ha scritto:
> I'm not sure how well I can explain this but something being in the
> spec and something in wide use are two different things, and people,
> including the ones in hw vendors, tend not to pay too much attention /
> resources to stuff which aren't used
Hey, Paolo.
On Fri, Jan 25, 2013 at 06:57:20PM +0100, Paolo Bonzini wrote:
> And because someone _will_ use it from my point of view, I can only give
> justification to leave stuff _out_. In general I did so if the command
> can disrupt someone else, as would be the case for persistent
>
Il 25/01/2013 18:28, Tejun Heo ha scritto:
> On Fri, Jan 25, 2013 at 06:16:04PM +0100, Paolo Bonzini wrote:
>> > Well, you can find broken devices for pretty much every command in the
>> > list. Anyhow, the other two commands are obsolete so I'm okay with
>> > leaving them out, if only for the
On Fri, Jan 25, 2013 at 06:16:04PM +0100, Paolo Bonzini wrote:
> Well, you can find broken devices for pretty much every command in the
> list. Anyhow, the other two commands are obsolete so I'm okay with
> leaving them out, if only for the sake of avoiding useless email threads.
Once we open
Il 25/01/2013 18:04, Tejun Heo ha scritto:
>> >
>> > I think it's the other way round. What's the justification for leaving
>> > them out, if they are in the standard? Since we're touching the
>> > commands for other standards, it's better to be complete for MMC as well.
> Maybe my experience
Hello, Paolo.
On Fri, Jan 25, 2013 at 10:26:09AM +0100, Paolo Bonzini wrote:
> > What are the justifications for adding these commands to the filter?
> > Are there users requesting these?
>
> I think it's the other way round. What's the justification for leaving
> them out, if they are in the
Il 24/01/2013 23:55, Tejun Heo ha scritto:
> On Thu, Jan 24, 2013 at 04:00:42PM +0100, Paolo Bonzini wrote:
>> Strangely, a couple of MMC commands were never included. Add them too.
>
> What are the justifications for adding these commands to the filter?
> Are there users requesting these?
I
Il 24/01/2013 23:55, Tejun Heo ha scritto:
On Thu, Jan 24, 2013 at 04:00:42PM +0100, Paolo Bonzini wrote:
Strangely, a couple of MMC commands were never included. Add them too.
What are the justifications for adding these commands to the filter?
Are there users requesting these?
I think
Hello, Paolo.
On Fri, Jan 25, 2013 at 10:26:09AM +0100, Paolo Bonzini wrote:
What are the justifications for adding these commands to the filter?
Are there users requesting these?
I think it's the other way round. What's the justification for leaving
them out, if they are in the
Il 25/01/2013 18:04, Tejun Heo ha scritto:
I think it's the other way round. What's the justification for leaving
them out, if they are in the standard? Since we're touching the
commands for other standards, it's better to be complete for MMC as well.
Maybe my experience with ATA left
On Fri, Jan 25, 2013 at 06:16:04PM +0100, Paolo Bonzini wrote:
Well, you can find broken devices for pretty much every command in the
list. Anyhow, the other two commands are obsolete so I'm okay with
leaving them out, if only for the sake of avoiding useless email threads.
Once we open the
Il 25/01/2013 18:28, Tejun Heo ha scritto:
On Fri, Jan 25, 2013 at 06:16:04PM +0100, Paolo Bonzini wrote:
Well, you can find broken devices for pretty much every command in the
list. Anyhow, the other two commands are obsolete so I'm okay with
leaving them out, if only for the sake of
Hey, Paolo.
On Fri, Jan 25, 2013 at 06:57:20PM +0100, Paolo Bonzini wrote:
And because someone _will_ use it from my point of view, I can only give
justification to leave stuff _out_. In general I did so if the command
can disrupt someone else, as would be the case for persistent
Il 25/01/2013 19:13, Tejun Heo ha scritto:
I'm not sure how well I can explain this but something being in the
spec and something in wide use are two different things, and people,
including the ones in hw vendors, tend not to pay too much attention /
resources to stuff which aren't used widely
Hey,
On Fri, Jan 25, 2013 at 07:47:47PM +0100, Paolo Bonzini wrote:
That doesn't happen. There's plenty of vendor-specific opcodes and mode
pages, not to mention out-of-band channels, e.g. work directly at the
USB level like the mode select stuff.
IIRC IOMEGA ZIP drives had some egregious
Il 25/01/2013 20:01, Tejun Heo ha scritto:
Some did that at least in ATA. It was mapping some command to
firmware write. Given how many USB devices implement SCSI these days,
I wouldn't be too firm with that doesn't happen. How can such
all-covering statement be asserted?
Of course it
Hello, Paolo.
On Fri, Jan 25, 2013 at 11:32:42PM +0100, Paolo Bonzini wrote:
All you can do is use common sense, which says that if a command has
been in a standard, someone has likely used it. Of course someone
_might_ have misused it too, but how likely is that?
So, that's where we differ,
Il 25/01/2013 23:41, Tejun Heo ha scritto:
Hello, Paolo.
On Fri, Jan 25, 2013 at 11:32:42PM +0100, Paolo Bonzini wrote:
All you can do is use common sense, which says that if a command has
been in a standard, someone has likely used it. Of course someone
_might_ have misused it too, but
Hello, Paolo.
On Sat, Jan 26, 2013 at 12:32:36AM +0100, Paolo Bonzini wrote:
If I make a whitelist with all the commands that Linux sends, I'll have
many new commands in the whitelist and no old commands. The new
commands didn't exist when old drives were sold, so they are dangerous
in your
On Thu, Jan 24, 2013 at 04:00:42PM +0100, Paolo Bonzini wrote:
> Strangely, a couple of MMC commands were never included. Add them too.
What are the justifications for adding these commands to the filter?
Are there users requesting these?
Thanks.
--
tejun
--
To unsubscribe from this list:
Strangely, a couple of MMC commands were never included. Add them too.
Cc: "James E.J. Bottomley"
Cc: linux-s...@kernel.org
Cc: Jens Axboe
Signed-off-by: Paolo Bonzini
---
block/scsi_ioctl.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/block/scsi_ioctl.c
Strangely, a couple of MMC commands were never included. Add them too.
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: linux-s...@kernel.org
Cc: Jens Axboe ax...@kernel.dk
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
block/scsi_ioctl.c |3 +++
1 files changed, 3 insertions(+),
On Thu, Jan 24, 2013 at 04:00:42PM +0100, Paolo Bonzini wrote:
Strangely, a couple of MMC commands were never included. Add them too.
What are the justifications for adding these commands to the filter?
Are there users requesting these?
Thanks.
--
tejun
--
To unsubscribe from this list: send
30 matches
Mail list logo
