Date: Thu, 07 Apr 2011 21:51:45 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: freebsd-scsi@FreeBSD.org Subject: Re: retry mounting with ro when rw fails Message-ID: <4D9E07C1.8070604@FreeBSD.org> In-Reply-To: <4D9DF234.2070803@feral.com> References: <4D9DEDF7.2070107@FreeBSD.org> <4D9DF234.2070803@feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 07/04/2011 20:19 Matthew Jacob said the following: > >> The first part is in CAM/SCSI to make sure that ENODEV is consistently returned to >> signal that an operation is not supported by a device (in accordance to intro(2)) >> and specifically to return ENODEV on write attempt to a read-only or >> write-protected media. Making this change in SCSI should cover real SCSI devices, >> as well as ATAPI through ahci/siis/atapicam or similar, plus majority (all?) of >> USB Mass Storage devices. > > This may be the right thing to do (which is debatable) but I can tell you here and I am always open to a debate. > now this will break a lot of commercial usages of FreeBSD with SANS which depend > (foolishly) on existing error codes. Do you mean EACCES -> ENODEV specifically? If yes, can you tell me how those application distinguish EACCES that means ro/wp media from EACCES that means there is something wrong with some permissions? Or EACCES that could be returned from cam_periph_mapmem? P.S. do you have specific applications in mind or do you speak hypothetically? P.P.S. the only reason for my EACCES -> ENODEV is that *I* wanted to be sure what error condition I am seeing. If compatibility is preferred over what I perceive as correctness, then be it, I would not insist. Thanks! -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D9E07C1.8070604>