public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rudolf Marek <r.marek@sh.cvut.cz>
To: Wim Van Sebroeck <wim@iguana.be>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] Watchdog device class
Date: Wed, 19 Apr 2006 23:24:56 +0200	[thread overview]
Message-ID: <4446AAA8.70907@sh.cvut.cz> (raw)
In-Reply-To: <20060419210204.GA4205@infomag.infomag.iguana.be>

Hello Wim,

> You can have a check now. I uploaded some code. Need to retest it, but it
> has been working on my v2.6.5 test machine.

Good I will check. I have one test machine provided by Asus, Winbond and me :)
(I'm using it for lm-sensors stuff) I can give you access if you give me ssh key.

> Don't agree here: boot_status is a copy of the status at boot. the status
> itself can change during normal operation. and thus get_status must return
> the "devices status" at that moment.

Ah correct, not always updated via async event, maybe the register is to be
polled only.

>>I have no such thing for the temp IOCTL but the new "ioctl" operation
>>could be created to catch it.
>>(and get called when no standard ioctl in watchdog-dev is used)
> 
> 
> I think we want to review the temperature stuff in the kernel in general.

If you mean in watchdog class, the yes. Otherwise no. The hwmon class has well
defined interface for a while...

> I still have to look at your driver in detail, but my first thought would
> be that the private part here would be a link to this common device structure.
> (see what I did with the example softdog implementation in the experimental tree).

Ok.

> It's not about different approaches: we have to find the best thing for watchdog
> devicesi, so the best thing is to talk about pro's and con's and see what we should 
> do best. (I for instance didn't come to the sysfs part yet of my code (which would
> be in watchdog_sysfs.c)

Ok I will look into your code.

>>Also I would like to know your ideas about the sysfs file structure for
>>watchdogs and also If you like to have more watchdogs active in the system or
>>just one.
> 
> 
> My view:
> to start we should keep one /dev/watchdog, but we should create/define a suitable
> sysfs interface that makes it possible to have multiple watchdog devices running 
> in parallel. We will need this functionality in the future when a system will 
> consist of different processors that all have their own memory and some basic
> I/O interfacing.
> Later on we will then see what we will do with /dev/watchdog.

I will let you know when I'm done with the studying of your code. I hope that I
will have some time in near fututure, got lot of stuff to do.

Regards
Rudolf

PS: CC me please.

  reply	other threads:[~2006-04-19 21:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-17 19:39 [RFC] Watchdog device class Rudolf Marek
2006-04-17 21:31 ` Alan Cox
2006-04-18 18:35   ` Rudolf Marek
2006-04-18 20:16     ` Alan Cox
2006-04-18  0:54 ` Arnd Bergmann
2006-04-18 19:32   ` Rudolf Marek
2006-04-18 22:24     ` Mark Rustad
2006-04-18 19:57 ` Wim Van Sebroeck
2006-04-18 20:59   ` Rudolf Marek
2006-04-19 21:02     ` Wim Van Sebroeck
2006-04-19 21:24       ` Rudolf Marek [this message]
2006-08-15 17:13         ` Wim Van Sebroeck
2006-09-14 12:19           ` Rudolf Marek
2006-04-18 23:07 ` Corey Minyard
2006-04-19 21:04   ` Wim Van Sebroeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4446AAA8.70907@sh.cvut.cz \
    --to=r.marek@sh.cvut.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wim@iguana.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox