From eugen@grosbein.pp.ru  Sat Sep 22 05:13:50 2007
Return-Path: <eugen@grosbein.pp.ru>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 354B516A418
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 22 Sep 2007 05:13:50 +0000 (UTC)
	(envelope-from eugen@grosbein.pp.ru)
Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.166])
	by mx1.freebsd.org (Postfix) with ESMTP id 9776913C45D
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 22 Sep 2007 05:13:49 +0000 (UTC)
	(envelope-from eugen@grosbein.pp.ru)
Received: from grosbein.pp.ru (localhost [127.0.0.1])
	by grosbein.pp.ru (8.14.1/8.14.1) with ESMTP id l8M5DlnX002007
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 22 Sep 2007 13:13:47 +0800 (KRAST)
	(envelope-from eugen@grosbein.pp.ru)
Received: (from eugen@localhost)
	by grosbein.pp.ru (8.14.1/8.14.1/Submit) id l8M5DlQw002006;
	Sat, 22 Sep 2007 13:13:47 +0800 (KRAST)
	(envelope-from eugen)
Message-Id: <200709220513.l8M5DlQw002006@grosbein.pp.ru>
Date: Sat, 22 Sep 2007 13:13:47 +0800 (KRAST)
From: Eugene Grosbein <eugen@grosbein.pp.ru>
Reply-To: Eugene Grosbein <eugen@grosbein.pp.ru>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: [fdc] [patch] fdc(4) does not respect hint.fd.0.flags from device.hints
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         116536
>Category:       kern
>Synopsis:       [fdc] [patch] fdc(4) does not respect hint.fd.0.flags from device.hints
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gavin
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Sep 22 05:20:00 GMT 2007
>Closed-Date:    Thu Jan 31 10:28:55 UTC 2008
>Last-Modified:  Thu Jan 31 10:28:55 UTC 2008
>Originator:     Eugene Grosbein
>Release:        FreeBSD 6.2-STABLE i386
>Organization:
Svyaz-Service JSC
>Environment:
System: FreeBSD grosbein.pp.ru 6.2-STABLE FreeBSD 6.2-STABLE #2: Sun Sep 16 16:54:23 KRAST 2007 eu@grosbein.pp.ru:/home/obj/usr/local/src/sys/DADV i386

>Description:
	Changing hint.fd.0.flags has no effect on fdc(4)

>How-To-Repeat:
	Try to change hint.fd.0.flags and see no change in behavour

>Fix:

--- sys/dev/fdc/fdc.c.orig	2007-09-15 16:53:23.000000000 +0800
+++ sys/dev/fdc/fdc.c	2007-09-16 16:26:07.000000000 +0800
@@ -1848,6 +1864,7 @@
 	fd->dev = dev;
 	fd->fdc = fdc;
 	fd->fdsu = fdsu;
+	fd->flags = flags;
 	unit = device_get_unit(dev);
 
 	/* Auto-probe if fdinfo is present, but always allow override. */
@@ -1857,7 +1874,7 @@
 		goto done;
 	} else {
 		/* make sure fdautoselect() will be called */
-		fd->flags = FD_EMPTY;
+		fd->flags |= FD_EMPTY;
 		fd->type = type;
 	}
 

>Release-Note:
>Audit-Trail:

From: Bruce Evans <brde@optusnet.com.au>
To: Eugene Grosbein <eugen@grosbein.pp.ru>
Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: kern/116536: [fdc] [patch] fdc(4) does not respect hint.fd.0.flags
 from device.hints
Date: Sat, 22 Sep 2007 18:27:17 +1000 (EST)

 On Sat, 22 Sep 2007, Eugene Grosbein wrote:
 
 >> Description:
 > 	Changing hint.fd.0.flags has no effect on fdc(4)
 > ...
 >> Fix:
 >
 > --- sys/dev/fdc/fdc.c.orig	2007-09-15 16:53:23.000000000 +0800
 > +++ sys/dev/fdc/fdc.c	2007-09-16 16:26:07.000000000 +0800
 > @@ -1848,6 +1864,7 @@
 > 	fd->dev = dev;
 > 	fd->fdc = fdc;
 > 	fd->fdsu = fdsu;
 > +	fd->flags = flags;
 > 	unit = device_get_unit(dev);
 >
 > 	/* Auto-probe if fdinfo is present, but always allow override. */
 
 fd->flags has nothing to do with the device flags.  This copy of the device
 flags gets clobbered later when fd->flags is used for more-dynamic flags.
 Note that this copy is for fd.x.flags.  There is also fdc.x.flags.
 
 Unbroken versions of fd call device_get_flags() in several places in
 order to get the device (fd or fdc) flags.  One of the places is just
 before the above in fdprobe() to get the fd flags, and the flags
 variable is used later in fdprobe(), so the fd flags still work in
 fdprobe().  This seems give correct behaviour for all currently supported
 fd flags.  However, device_get_flags() is never called to get the fdc
 flags, so fdc flags don't work.
 
 > @@ -1857,7 +1874,7 @@
 > 		goto done;
 > 	} else {
 > 		/* make sure fdautoselect() will be called */
 > -		fd->flags = FD_EMPTY;
 > +		fd->flags |= FD_EMPTY;
 > 		fd->type = type;
 > 	}
 >
 
 In particular, FD_EMPTY is (1<<3), so this setting of a dynamic flag
 clobbers the fd flag for the top bit in FD_TYPEMASK.  This may be
 harmless, but setting other low bits in FD_TYPEMASK from the fd flags
 probably breaks them.
 
 The only fd flag other than FD_TYPEMASK is 0x20 (FD_NO_PROBE).  This
 is only used in fdprobe(), so it still seems to work correctly.  0x20
 in fd->flags is FD_ISA_DMA.  This is unrelated.
 
 The hole at 0x10 is for the changeline flag which you are unbreaking
 in another PR.  This used to be read in Fdopen().  Confusion was
 increased by spelling the variable that holds it dflags while the
 variable that holds it in the above is spelled flag.  Old confusion
 starts with not using the fd_ prefix for the flags struct member.
 This bug has been fixed for many of the struct members associated
 with the fd, but not for flags.  (Older code generally uses a prefix
 for fdc members but no prefix for fd members.)
 
 The only documented fdc flag is 0x1 (no fifo).  This apparently never
 worked, but only the man page was broken.  The flag was actually
 (1 << 2) (FDC_NO_FIFO).  Now the man page still says 0x1 but
 FDC_NO_FIFO is not defined and the fdc flags are never read.
 
 Bruce

From: Eugene Grosbein <eugen@grosbein.pp.ru>
To: bug-followup@freebsd.org
Cc: Bruce Evans <brde@optusnet.com.au>
Subject: Re: kern/116536: [fdc] [patch] fdc(4) does not respect hint.fd.0.flags from device.hints
Date: Tue, 25 Sep 2007 00:56:54 +0800

 On Sat, 22 Sep 2007, Bruce Evans wrote:
 
 > fd->flags has nothing to do with the device flags.  This copy of the device
 > flags gets clobbered later when fd->flags is used for more-dynamic flags.
 
 int has (at least) 32 bits, why not use them?
 It's possible to move values for user-settable flags 
 (that are broken anyway for now) so that they do not globber
 with more-dynamic flags. What's the point in calls to device_get_flags()
 all the way?
 
 Eugene Grosbein

From: Bruce Evans <brde@optusnet.com.au>
To: Eugene Grosbein <eugen@grosbein.pp.ru>
Cc: bug-followup@freebsd.org, Bruce Evans <brde@optusnet.com.au>
Subject: Re: kern/116536: [fdc] [patch] fdc(4) does not respect hint.fd.0.flags
 from device.hints
Date: Tue, 25 Sep 2007 03:15:19 +1000 (EST)

 On Tue, 25 Sep 2007, Eugene Grosbein wrote:
 
 > On Sat, 22 Sep 2007, Bruce Evans wrote:
 >
 >> fd->flags has nothing to do with the device flags.  This copy of the device
 >> flags gets clobbered later when fd->flags is used for more-dynamic flags.
 >
 > int has (at least) 32 bits, why not use them?
 
 It's simpler to use another variable for unrelated flags.
 
 > It's possible to move values for user-settable flags
 > (that are broken anyway for now) so that they do not globber
 > with more-dynamic flags. What's the point in calls to device_get_flags()
 > all the way?
 
 It is to keep the device flags in the variable (struct member) where
 they belong.  They could be cached in a driver variable (struct member),
 but there is no point.  device_get_flags() is just "return (dev->dev_flags);"
 and its speed is so unimportant that it is not inline.
 
 Bruce
State-Changed-From-To: open->feedback 
State-Changed-By: gavin 
State-Changed-When: Sun Jan 27 20:10:23 UTC 2008 
State-Changed-Why:  
To submitter: As far as I can tell, fdc(4) seems to be handling flags set 
through hint.fd.0.flags correctly.  If you still believe this to be an issue, 
can you give an example of what you are trying to do and what you believe 
should be happening please? 


Responsible-Changed-From-To: freebsd-bugs->gavin 
Responsible-Changed-By: gavin 
Responsible-Changed-When: Sun Jan 27 20:10:23 UTC 2008 
Responsible-Changed-Why:  
Track 

http://www.freebsd.org/cgi/query-pr.cgi?pr=116536 

From: Eugene Grosbein <eugen@kuzbass.ru>
To: bug-followup@freebsd.org
Cc: gavin@freebsd.org
Subject: Re: kern/116536: [fdc] [patch] fdc(4) does not respect hint.fd.0.flags from device.hints
Date: Tue, 29 Jan 2008 23:10:05 +0700

 On Sun, Jan 27, 2008 at 08:14:29PM +0000, gavin@FreeBSD.org wrote:
 > Synopsis: [fdc] [patch] fdc(4) does not respect hint.fd.0.flags from device.hints
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: gavin
 > State-Changed-When: Sun Jan 27 20:10:23 UTC 2008
 > State-Changed-Why: 
 > To submitter: As far as I can tell, fdc(4) seems to be handling flags set
 > through hint.fd.0.flags correctly.  If you still believe this to be an issue,
 > can you give an example of what you are trying to do and what you believe
 > should be happening please?
 
 This PR came to be from the problem described in another fdc(4) PR:
 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/116538
 
 In short: we need to restore suppoprt for per-device flags (hints)
 for fdc(4). One such flag was ever named FD_NO_CHLINE and was designed
 to mark FDDs that have no (or broken) media change line support.
 
 The flag FD_NO_CHLINE was removed long time ago with kernel support
 for such floppy drives. Now we need it back. I've tried to restore
 such support and found that fdc(4) in sys/dev/fdc/fdc.c
 does not keep per-device hints obtained with device_get_flags(dev)
 in fd_probe() function nor calls device_get_flags(dev) later.
 I decided to keep hints obtained via device_get_flags(dev)
 in the fd->flags structure member so fdc(4) could use it later.
 An example of such usage is in kern/116538.
 
 Bruce Evans said this is wong style. Perhaps, he's right.
 But the problem(s) that this PR and kern/116538 talk about
 are still here, I've been using the patches presented
 during 5 months and they work for me. This style or another -
 the problem needs to be solved.
 
 Eugene Grosbein
State-Changed-From-To: feedback->closed 
State-Changed-By: gavin 
State-Changed-When: Thu Jan 31 10:18:52 UTC 2008 
State-Changed-Why:  
After discussion with the submitter, the real issue is that in PR 
kern/116538.  Close this one. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=116536 
>Unformatted:
