Re: One more question (different now)
On 10-May-00 Doug Rabson wrote: > On Tue, 9 May 2000, Mike Smith wrote: > >> > On Tue, May 09, 2000 at 04:27:10PM -0700, Mike Smith wrote: >> > > The only answer I've seen for this one is to kick, hard, whoever it was >> > > that added -Wcast-qual to the kernel options. >> > >> > Or we should just delete it from the options. >> >> Ugh. I don't actually like that, because it serves a valid purpose. >> What irritates me mostly is just that there is no way of casting a >> volatile object into a non-volatile type, so you can't implement any sort >> of conditional volatility exclusion. > > You can suppress the warning if you cast to uintptr_t first. Pretty ugly > though. It actually worked! Now I will go and see what this uintptr_t actually is :-) > > -- > Doug Rabson Mail: [EMAIL PROTECTED] > Nonlinear Systems Ltd.Phone: +44 20 8442 9037 > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message Sincerely Yours 404.664.6401 Simon Shapiro Research Fellow, Earthlink Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: EVENTHANDLER_DECLARE
On 10-May-00 Mike Smith wrote: ... >> This is dangerous for the OSM. When the i2o OSM shuts an IOP >> down, it is history. It will stop doing any work at all; network, >> disk, console, mouse, whatever. I reserve that for really, really >> shutdown/reset. > > I'm not sure I understand what you mean by "dangerous". When your > shutdown method is called, you're being told that you're about to stop > being able to control your hardware, either because your code is about to > be removed from the kernel (module unload) or because the system is being > shut down. (perhaps) Dangerous in the sense that the i2o OSM handles multiple diciplines. It is not a disk-only driver. It has a disk component but if I shut down the IOPs more than just disks stop. Thus I need to be sure the OSM is the very last to be called. > Before you return success from your shutdown method, you must have > brought your hardware to a quiescent state, ready for immediate loss of > power. It must not generate any more interrupts or access any more data > once you have returned. That is already being done. Thanx. > You can veto your shutdown (by returning nonzero), which will fail a > module unload, but _will_not_ fail a kernel shutdown. That is fine. >> This needs to happen after all other shutdown work was done, >> but before a physical reset is sent to the hardware. >> >> There is no telling how long the IOP will take to return >> from flush request. > > That's fine. Again, the Mylex driver is doing exactly what you're > talking about; I've been down this path just a few times now. 8) > >> > (Note that the Mylex stuff doesn't correctly handle suspend/resume since >> > we don't have a decent ACPI implementation yet) >> >> I can emulate suspend/resume in the OSM easily. >> Actually, it does that just before shutting down. >> A single line of code. > > I'm assuming that you depend on the platform firmware to bring it out of > any of the deep sleep modes, re-enumerate the PCI bus and restore all of > its volatile state? Nope. I maintain a state machine in the OSM that makes sure there is nothing pending on the IOP. Shutting down the IOP is a mess. Bringing it back up is even bigger mess. It is simpler the way I do it. Besides, different vendors implement i2o in different ways. Some do not even have a facility for sane shutdown. > -- > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] > \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message Sincerely Yours 404.664.6401 Simon Shapiro Research Fellow, Earthlink Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: One more question (different now)
On 09-May-00 Mike Smith wrote: >> On Tue, May 09, 2000 at 04:27:10PM -0700, Mike Smith wrote: >> > The only answer I've seen for this one is to kick, hard, whoever it was >> > that added -Wcast-qual to the kernel options. >> >> Or we should just delete it from the options. > > Ugh. I don't actually like that, because it serves a valid purpose. > What irritates me mostly is just that there is no way of casting a > volatile object into a non-volatile type, so you can't implement any sort > of conditional volatility exclusion. Agree. It is a mess. Ideally, if an object is volatile, then it should be respected as so. always. The ANSI standard is too vague on this issue and the number of poor suckers that have to have it is too small. > -- > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] > \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message Sincerely Yours 404.664.6401 Simon Shapiro Research Fellow, Earthlink Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: EVENTHANDLER_DECLARE
On 10-May-00 Mike Smith wrote: >> Sorry to bother y'll, but; >> >> Has anyone ever used that? I see no trace of any kernel >> code calling it, and the at_shutdown code appears to be >> gone. > > It's still used in the shutdown code; it was meant to be available for > general use elsewhere, but I haven't seen anyone playing with it, so > maybe the design tradeoffs were bad choices. I dunno. It seems to do anything I need; Call me with an argument. I do not even need the priority. >> BTW, for all it is worth, any caching controller not using >> this is guaranteed to lose data. > > Wrong layer. You should be using the bus shutdown method; look at eg. > the Mylex driver to see how this is done. You should probably call your > flush routine from the suspend method as well. This is dangerous for the OSM. When the i2o OSM shuts an IOP down, it is history. It will stop doing any work at all; network, disk, console, mouse, whatever. I reserve that for really, really shutdown/reset. This needs to happen after all other shutdown work was done, but before a physical reset is sent to the hardware. There is no telling how long the IOP will take to return from flush request. > (Note that the Mylex stuff doesn't correctly handle suspend/resume since > we don't have a decent ACPI implementation yet) I can emulate suspend/resume in the OSM easily. Actually, it does that just before shutting down. A single line of code. > -- > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] > \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message Sincerely Yours 404.664.6401 Simon Shapiro Research Fellow, Earthlink Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: EVENTHANDLER_DECLARE - solved
Correction to the below message;
Figured it out all by myself :-)
Thanx!
On 10-May-00 Simon Shapiro wrote:
> Sorry to bother y'll, but;
>
> Has anyone ever used that? I see no trace of any kernel
> code calling it, and the at_shutdown code appears to be
> gone.
>
> BTW, for all it is worth, any caching controller not using
> this is guaranteed to lose data.
>
> that can range from 4MB to 256MB, all of which the kernel
> is convinced was written to disk. IOW, disaster.
>
>
> Sincerely Yours
> 404.664.6401
> Simon Shapiro Research Fellow, Earthlink Inc.
Sincerely Yours
404.664.6401
Simon Shapiro Research Fellow, Earthlink Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: One more question (different now)
On 10-May-00 Marcel Moolenaar wrote:
> Mike Smith wrote:
>>
>> Ugh. I don't actually like that, because it serves a valid purpose.
>> What irritates me mostly is just that there is no way of casting a
>> volatile object into a non-volatile type, so you can't implement any sort
>> of conditional volatility exclusion.
>
> You can however use a union and have a non-volatile object aliasing a
> volatile object as in:
>
> union u {
> volatile int vi;
> int nvi;
> };
And you know for a fact that the compiler will generate
the right code. Right? :-)
Even if it did, I feel nervous. What if, in the example
above, the generated code does not clear the structure
on time, as indicated? What about other cases where
references to volatile data are being made?
Thanx for the tip, though...!
>
> --
> Marcel Moolenaar
> mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
> tel: (408) 447-4222
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
Sincerely Yours
404.664.6401
Simon Shapiro Research Fellow, Earthlink Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
EVENTHANDLER_DECLARE
Sorry to bother y'll, but; Has anyone ever used that? I see no trace of any kernel code calling it, and the at_shutdown code appears to be gone. BTW, for all it is worth, any caching controller not using this is guaranteed to lose data. that can range from 4MB to 256MB, all of which the kernel is convinced was written to disk. IOW, disaster. Sincerely Yours 404.664.6401 Simon Shapiro Research Fellow, Earthlink Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
One more question (different now)
Hi Again,
Since you were so kind to me, I will impose another
one on you (the previous answers were _all_ correct! )
Given:
typedef struct junk {
...
} junk_t
volatile junk_t trash;
What I want to do is zero out trash.
bzero(trash, sizeof(junk_t));
produces a warning about loss of volatility.
So does:
bzero((void *)&trash, sizeof(junk_t));
So, how do I make everyone happy?
Oh, the struct has to be volatile. Trust me on that one.
Sincerely Yours
404.664.6401
Simon Shapiro Research Fellow, Earthlink Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Compilation Question
Hi Y'll A kernel source file that compiles flawlessly on RELEG_3, gives (among many others, these warnings: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wm issing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ans i -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../i2o/i2o_drv.c In file included from ../../i2o/include/i2oadptr.h:32, from ../../i2o/i2o_drv.c:357: ../../i2o/include/i2omsg.h: warning: 1 trigraph(s) encountered In file included from ../../i2o/include/i2obscsi.h:29, from ../../i2o/i2o_drv.c:358: ../../i2o/include/i2omsg.h: warning: 1 trigraph(s) encountered In file included from ../../i2o/include/i2oexec.h:37, from ../../i2o/i2o_drv.c:362: ../../i2o/include/i2omsg.h: warning: 1 trigraph(s) encountered In file included from ../../i2o/include/i2outil.h:37, from ../../i2o/include/i2oexec.h:38, from ../../i2o/i2o_drv.c:362: ../../i2o/include/i2omsg.h: warning: 1 trigraph(s) encountered In file included from ../../i2o/i2o_drv.c:363: ../../i2o/include/i2omsg.h: warning: 1 trigraph(s) encountered I have _no clue_ which line in the file does that. Tried to isolate it to no avail. Can you please tell me what does this wanring mean? Personal replies as to not clutter the list will be very appreciated. Thanx! Sincerely Yours 404.664.6401 Simon Shapiro Research Fellow, Earthlink Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
