linux-kernel - Re: [PATCH] scsi: remove CDROM not ready printk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1212069932.3428.1.camel@localhost.localdomain>
Date:	Thu, 29 May 2008 09:05:32 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Jerry Stralko <gerb.stralko@...il.com>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [PATCH] scsi: remove CDROM not ready printk

On Thu, 2008-05-29 at 00:41 -0700, Andrew Morton wrote:
> On Tue, 27 May 2008 15:02:43 -0400 (EDT) Jerry Stralko <gerb.stralko@...il.com> wrote:
> 
> > Hello,
> 
> let's cc a scsi list which exists ;)
> 
> >    This printk was spamming my dmesg and /var/log/message.  Is there a 
> > reason we have this printk?  Can we simply remove it?
> > 
> > 
> > Signed-off-by: Jerry Stralko <gerb.stralko@...il.com>
> > ---
> > 
> > 
> > diff --git a/drivers/scsi/sr_ioctl.c b/drivers/scsi/sr_ioctl.c
> > index ae87d08..c37fb1c 100644
> > --- a/drivers/scsi/sr_ioctl.c
> > +++ b/drivers/scsi/sr_ioctl.c
> > @@ -238,8 +238,6 @@ int sr_do_ioctl(Scsi_CD *cd, struct packet_command *cgc)
> >   					break;
> >   				}
> >   			}
> > -			if (!cgc->quiet)
> > -				printk(KERN_INFO "%s: CDROM not ready.  Make sure there is a disc in the drive.\n", cd->cdi.name);
> >   #ifdef DEBUG
> >   			scsi_print_sense_hdr("sr", &sshdr);
> >   #endif
> 
> The answer may be that you need to enable cgc->quiet.  If that is
> user-enableable - I can't work out how from a quick grep.

That's correct.  cgc is the data from the packet command that was sent
in from the ioctl.  The user application is actually the one that
decides whether you get to see the message or not.  Modern apps like hal
set it because they take care of all state updates and notifications
themselves.  Which is the application that's doing this (because it
probably needs updating).

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/