On Aug 17, 2005, at 01:33:00, Matt Domsch wrote:
This is conceptually similar to how SCSI Generic (either
/dev/sg or ioctl(SG_IO)) works (userspace passes in preformated SCSI
CDBs and gets back the resultant CDBs and extended sense data). The
sg driver doesn't look at the data being passed down
On Aug 17, 2005, at 01:33:00, Matt Domsch wrote:
This is conceptually similar to how SCSI Generic (either
/dev/sg or ioctl(SG_IO)) works (userspace passes in preformated SCSI
CDBs and gets back the resultant CDBs and extended sense data). The
sg driver doesn't look at the data being passed down
On Tue, Aug 16, 2005 at 06:47:45PM -0500, [EMAIL PROTECTED] wrote:
> > From: Greg KH [mailto:[EMAIL PROTECTED]
> > > And just to re-iterate one more time, we can already directly hook
> > > into
> > > hardware from userspace without any kernel auditing. We are
> > just trying
> > > to set this
On Wed, 2005-08-17 at 02:23 +0200, Andi Kleen wrote:
> <[EMAIL PROTECTED]> writes:
> > 2) Dell OpenManage
> > The main use of this driver by openmanage will be to read the System
> > Event Log that BIOS keeps. Here are some other random relevant points:
>
> Are there machine check events
<[EMAIL PROTECTED]> writes:
> 2) Dell OpenManage
> The main use of this driver by openmanage will be to read the System
> Event Log that BIOS keeps. Here are some other random relevant points:
Are there machine check events from the last boot in that event log?
If yes it would be extremly
> -Original Message-
> From: Greg KH [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 16, 2005 6:24 PM
> To: Brown, Michael E
> Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
> Warzecha, Douglas; Domsch, Matt
> Subject: Re: [RFC][PATCH 2.6.13-rc6] add Dell
On Mon, Aug 15, 2005 at 10:52:48PM -0700, Greg KH wrote:
> On Mon, Aug 15, 2005 at 03:05:22PM -0500, Doug Warzecha wrote:
> > +
> > +1) Lock smi_data.
> > +2) Determine buffer size needed for system management command.
> > +3) Write buffer size needed to smi_data_buf_size.
> > + (Driver will
On Tue, Aug 16, 2005 at 06:11:13PM -0500, [EMAIL PROTECTED] wrote:
>
> The main use of this driver by libsmbios will be to set BIOS F2
> options. Based on your feedback, I will _NOT_ be implementing any
> fan/sensor functionality in libsmbios, but will work with the lmsensors
> guys to do
Greg KH wrote:
>On Tue, Aug 16, 2005 at 08:34:24AM -0500, Michael E Brown wrote:
>
>
>>On Tue, 2005-08-16 at 01:16 -0700, Greg KH wrote:
>>
>>
>>>No, export this data properly through sysfs like all other temperature
>>>and sensor data is. Don't create a new one, no matter how much you
On Tue, Aug 16, 2005 at 08:34:24AM -0500, Michael E Brown wrote:
> On Tue, 2005-08-16 at 01:16 -0700, Greg KH wrote:
> > On Mon, Aug 15, 2005 at 10:10:28PM -0500, Michael E Brown wrote:
> > > To take a concrete example, I suggested to Doug to mention fan status. I
> > > get the feeling that you
Hi!
> > > To take a concrete example, I suggested to Doug to mention fan status. I
> > > get the feeling that you possibly think that this would be better
> > > integrated into lmsensors, or something like that.
> >
> > Yes it should. That way you get the benifit of all userspace
> >
On Tue, 2005-08-16 at 01:16 -0700, Greg KH wrote:
> On Mon, Aug 15, 2005 at 10:10:28PM -0500, Michael E Brown wrote:
> > To take a concrete example, I suggested to Doug to mention fan status. I
> > get the feeling that you possibly think that this would be better
> > integrated into lmsensors, or
On 228, 08 16, 2005 at 01:36:19AM -0400, [EMAIL PROTECTED] wrote:
> On Mon, 15 Aug 2005 23:58:43 CDT, Michael E Brown said:
>
> > No, this is an _EXCELLENT_ reason why _LESS_ of this should be in the
> > kernel. Why should we have to duplicate a _TON_ of code inside the
> > kernel to figure out
On Mon, Aug 15, 2005 at 10:10:28PM -0500, Michael E Brown wrote:
> To take a concrete example, I suggested to Doug to mention fan status. I
> get the feeling that you possibly think that this would be better
> integrated into lmsensors, or something like that.
Yes it should. That way you get the
On Tue, 16 Aug 2005 01:10:23 CDT, Michael E Brown said:
> Ok, very nice. Finally some actual code review, thanks. :-)
I have to admit I'm not qualified to do a detailed review, but I try.. ;)
> These are all just standard CMOS port numbers that pretty much every
> chipset uses to access CMOS.
On Mon, Aug 15, 2005 at 03:05:22PM -0500, Doug Warzecha wrote:
> This patch adds the Dell Systems Management Base Driver with sysfs support.
>
> This driver has been tested with Dell OpenManage.
Much better, but I still have a few questions:
> +System Management Interrupt
> +
> +On some Dell
On Tue, 2005-08-16 at 01:36 -0400, [EMAIL PROTECTED] wrote:
> On Mon, 15 Aug 2005 23:58:43 CDT, Michael E Brown said:
>
> > No, this is an _EXCELLENT_ reason why _LESS_ of this should be in the
> > kernel. Why should we have to duplicate a _TON_ of code inside the
> > kernel to figure out which
On Mon, Aug 15, 2005 at 10:10:28PM -0500, Michael E Brown wrote:
> On Mon, 2005-08-15 at 21:29 -0400, Kyle Moffett wrote:
> > On Aug 15, 2005, at 18:58:56, [EMAIL PROTECTED] wrote:
> > >> Why can't you just implement the system management actions in
> > >> the kernel driver? This is tantamount to
On Mon, Aug 15, 2005 at 10:10:28PM -0500, Michael E Brown wrote:
On Mon, 2005-08-15 at 21:29 -0400, Kyle Moffett wrote:
On Aug 15, 2005, at 18:58:56, [EMAIL PROTECTED] wrote:
Why can't you just implement the system management actions in
the kernel driver? This is tantamount to a binary
On Tue, 2005-08-16 at 01:36 -0400, [EMAIL PROTECTED] wrote:
On Mon, 15 Aug 2005 23:58:43 CDT, Michael E Brown said:
No, this is an _EXCELLENT_ reason why _LESS_ of this should be in the
kernel. Why should we have to duplicate a _TON_ of code inside the
kernel to figure out which platform
On Mon, Aug 15, 2005 at 03:05:22PM -0500, Doug Warzecha wrote:
This patch adds the Dell Systems Management Base Driver with sysfs support.
This driver has been tested with Dell OpenManage.
Much better, but I still have a few questions:
+System Management Interrupt
+
+On some Dell systems,
On Tue, 16 Aug 2005 01:10:23 CDT, Michael E Brown said:
Ok, very nice. Finally some actual code review, thanks. :-)
I have to admit I'm not qualified to do a detailed review, but I try.. ;)
These are all just standard CMOS port numbers that pretty much every
chipset uses to access CMOS.
The
On Mon, Aug 15, 2005 at 10:10:28PM -0500, Michael E Brown wrote:
To take a concrete example, I suggested to Doug to mention fan status. I
get the feeling that you possibly think that this would be better
integrated into lmsensors, or something like that.
Yes it should. That way you get the
On 228, 08 16, 2005 at 01:36:19AM -0400, [EMAIL PROTECTED] wrote:
On Mon, 15 Aug 2005 23:58:43 CDT, Michael E Brown said:
No, this is an _EXCELLENT_ reason why _LESS_ of this should be in the
kernel. Why should we have to duplicate a _TON_ of code inside the
kernel to figure out which
On Tue, 2005-08-16 at 01:16 -0700, Greg KH wrote:
On Mon, Aug 15, 2005 at 10:10:28PM -0500, Michael E Brown wrote:
To take a concrete example, I suggested to Doug to mention fan status. I
get the feeling that you possibly think that this would be better
integrated into lmsensors, or
Hi!
To take a concrete example, I suggested to Doug to mention fan status. I
get the feeling that you possibly think that this would be better
integrated into lmsensors, or something like that.
Yes it should. That way you get the benifit of all userspace
applications that already
On Tue, Aug 16, 2005 at 08:34:24AM -0500, Michael E Brown wrote:
On Tue, 2005-08-16 at 01:16 -0700, Greg KH wrote:
On Mon, Aug 15, 2005 at 10:10:28PM -0500, Michael E Brown wrote:
To take a concrete example, I suggested to Doug to mention fan status. I
get the feeling that you possibly
Greg KH wrote:
On Tue, Aug 16, 2005 at 08:34:24AM -0500, Michael E Brown wrote:
On Tue, 2005-08-16 at 01:16 -0700, Greg KH wrote:
No, export this data properly through sysfs like all other temperature
and sensor data is. Don't create a new one, no matter how much you
would like to keep
On Tue, Aug 16, 2005 at 06:11:13PM -0500, [EMAIL PROTECTED] wrote:
The main use of this driver by libsmbios will be to set BIOS F2
options. Based on your feedback, I will _NOT_ be implementing any
fan/sensor functionality in libsmbios, but will work with the lmsensors
guys to do this
On Mon, Aug 15, 2005 at 10:52:48PM -0700, Greg KH wrote:
On Mon, Aug 15, 2005 at 03:05:22PM -0500, Doug Warzecha wrote:
+
+1) Lock smi_data.
+2) Determine buffer size needed for system management command.
+3) Write buffer size needed to smi_data_buf_size.
+ (Driver will ensure that
-Original Message-
From: Greg KH [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 16, 2005 6:24 PM
To: Brown, Michael E
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
Warzecha, Douglas; Domsch, Matt
Subject: Re: [RFC][PATCH 2.6.13-rc6] add Dell Systems
Management Base
[EMAIL PROTECTED] writes:
2) Dell OpenManage
The main use of this driver by openmanage will be to read the System
Event Log that BIOS keeps. Here are some other random relevant points:
Are there machine check events from the last boot in that event log?
If yes it would be extremly cool
On Wed, 2005-08-17 at 02:23 +0200, Andi Kleen wrote:
[EMAIL PROTECTED] writes:
2) Dell OpenManage
The main use of this driver by openmanage will be to read the System
Event Log that BIOS keeps. Here are some other random relevant points:
Are there machine check events from the last
On Tue, Aug 16, 2005 at 06:47:45PM -0500, [EMAIL PROTECTED] wrote:
From: Greg KH [mailto:[EMAIL PROTECTED]
And just to re-iterate one more time, we can already directly hook
into
hardware from userspace without any kernel auditing. We are
just trying
to set this out on the
On Mon, 2005-08-15 at 22:35 -0700, Chris Wedgwood wrote:
> On Tue, Aug 16, 2005 at 12:19:49AM -0500, Michael E Brown wrote:
>
> > Hmm... did I mention libsmbios? :-)
> > http://linux.dell.com/libsmbios/main.
>
> I'm aware of it --- it seems pretty limited right now and I'm still
> irked Dell
On Mon, 15 Aug 2005 23:58:43 CDT, Michael E Brown said:
> No, this is an _EXCELLENT_ reason why _LESS_ of this should be in the
> kernel. Why should we have to duplicate a _TON_ of code inside the
> kernel to figure out which platform we are on, and then look up in a
> table which method to use
On Tue, Aug 16, 2005 at 12:19:49AM -0500, Michael E Brown wrote:
> Hmm... did I mention libsmbios? :-)
> http://linux.dell.com/libsmbios/main.
I'm aware of it --- it seems pretty limited right now and I'm still
irked Dell isn't more forthcoming with documentation.
> SMI support is not yet
On Tue, 2005-08-16 at 01:17 -0400, [EMAIL PROTECTED] wrote:
> On Mon, 15 Aug 2005 23:09:28 CDT, you said:
>
> > No, dcdbas has nothing to do with this. I'll have to submit a patch
> > against the docs. The program you need to use already exists and is
> > open source. You can use libsmbios to do
Again, please cc Doug and I on replies...
Kyle Moffett wrote:
>On Aug 16, 2005, at 00:34:51, Chris Wedgwood wrote:
>> On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
>>> Why can't you just implement the system management actions in the
>>> kernel driver?
>>
>> Why put things in the
On Mon, 15 Aug 2005 23:09:28 CDT, you said:
> No, dcdbas has nothing to do with this. I'll have to submit a patch
> against the docs. The program you need to use already exists and is
> open source. You can use libsmbios to do this.
> http://linux.dell.com/libsmbios/main.
Now I'm confoozled.
On Tue, Aug 16, 2005 at 12:55:35AM -0400, Kyle Moffett wrote:
> I'm worried that it might be more of a mess in userspace than it
> could be if done properly in the kernel.
I would rather if it's gonna be a mess it's, then we put that mess in
userspace rather than in the kernel.
> Hardware
I am not subscribed to linux-kernel. Please cc me (and Doug) on all
replies. Sorry if I'm breaking peoples threading, but I am cut-and-
pasting this from web archives, since this wasn't cc-d to me
originally.
>On Aug 15, 2005, at 19:38:49, Doug Warzecha wrote:
>> On Mon, Aug 15, 2005 at
On Aug 16, 2005, at 00:34:51, Chris Wedgwood wrote:
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
Why can't you just implement the system management actions in the
kernel driver?
Why put things in the kernel unless it's really needed?
I'm not thrillied about the lack of
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
> Why can't you just implement the system management actions in the
> kernel driver?
Why put things in the kernel unless it's really needed?
I'm not thrillied about the lack of userspace support for this driver
but that still doesn't
>On Mon, 15 Aug 2005 18:38:49 CDT, Doug Warzecha said:
>
>> > If this is supposed to be used with the RBU code to trigger a BIOS
>> > update, ...
>>
>> This driver is not needed by the RBU code.
>
> Documentation/dell_rbu.txt says:
>
>> The rbu driver needs to have an application which will
On Mon, 2005-08-15 at 21:29 -0400, Kyle Moffett wrote:
> On Aug 15, 2005, at 18:58:56, [EMAIL PROTECTED] wrote:
> >> Why can't you just implement the system management actions in
> >> the kernel driver? This is tantamount to a binary SMI hook to
> >> userspace. What functionality does this
On Mon, 15 Aug 2005 18:38:49 CDT, Doug Warzecha said:
> > If this is supposed to be used with the RBU code to trigger a BIOS
> > update, ...
>
> This driver is not needed by the RBU code.
Documentation/dell_rbu.txt says:
> The rbu driver needs to have an application which will inform the
On Aug 15, 2005, at 19:38:49, Doug Warzecha wrote:
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
Why can't you just implement the system management actions in the
kernel
driver?
We want to minimize the amount of code in the kernel and avoid
having to
update the driver
On Aug 15, 2005, at 18:58:56, [EMAIL PROTECTED] wrote:
Why can't you just implement the system management actions in
the kernel driver? This is tantamount to a binary SMI hook to
userspace. What functionality does this provide on a dell
system from an administrator's point of view?
Kyle,
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
> On Aug 15, 2005, at 16:05:22, Doug Warzecha wrote:
> >This patch adds the Dell Systems Management Base Driver with sysfs
> >support.
>
> >+On some Dell systems, systems management software must access certain
> >+management
>> +On some Dell systems, systems management software must access
certain
>> +management information via a system management interrupt (SMI).
>> The SMI data
>> +buffer must reside in 32-bit address space, and the physical
>> address of the
>> +buffer is required for the SMI. The driver
On Aug 15, 2005, at 16:05:22, Doug Warzecha wrote:
This patch adds the Dell Systems Management Base Driver with sysfs
support.
+On some Dell systems, systems management software must access certain
+management information via a system management interrupt (SMI).
The SMI data
+buffer must
This patch adds the Dell Systems Management Base Driver with sysfs support.
This driver has been tested with Dell OpenManage.
Signed-off-by: Doug Warzecha <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.13-rc6.orig/Documentation/dcdbas.txt
linux-2.6.13-rc6/Documentation/dcdbas.txt
---
This patch adds the Dell Systems Management Base Driver with sysfs support.
This driver has been tested with Dell OpenManage.
Signed-off-by: Doug Warzecha [EMAIL PROTECTED]
---
diff -uprN linux-2.6.13-rc6.orig/Documentation/dcdbas.txt
linux-2.6.13-rc6/Documentation/dcdbas.txt
---
On Aug 15, 2005, at 16:05:22, Doug Warzecha wrote:
This patch adds the Dell Systems Management Base Driver with sysfs
support.
+On some Dell systems, systems management software must access certain
+management information via a system management interrupt (SMI).
The SMI data
+buffer must
+On some Dell systems, systems management software must access
certain
+management information via a system management interrupt (SMI).
The SMI data
+buffer must reside in 32-bit address space, and the physical
address of the
+buffer is required for the SMI. The driver maintains the
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
On Aug 15, 2005, at 16:05:22, Doug Warzecha wrote:
This patch adds the Dell Systems Management Base Driver with sysfs
support.
+On some Dell systems, systems management software must access certain
+management information via a
On Aug 15, 2005, at 18:58:56, [EMAIL PROTECTED] wrote:
Why can't you just implement the system management actions in
the kernel driver? This is tantamount to a binary SMI hook to
userspace. What functionality does this provide on a dell
system from an administrator's point of view?
Kyle,
On Aug 15, 2005, at 19:38:49, Doug Warzecha wrote:
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
Why can't you just implement the system management actions in the
kernel
driver?
We want to minimize the amount of code in the kernel and avoid
having to
update the driver
On Mon, 15 Aug 2005 18:38:49 CDT, Doug Warzecha said:
If this is supposed to be used with the RBU code to trigger a BIOS
update, ...
This driver is not needed by the RBU code.
Documentation/dell_rbu.txt says:
The rbu driver needs to have an application which will inform the BIOS to
On Mon, 2005-08-15 at 21:29 -0400, Kyle Moffett wrote:
On Aug 15, 2005, at 18:58:56, [EMAIL PROTECTED] wrote:
Why can't you just implement the system management actions in
the kernel driver? This is tantamount to a binary SMI hook to
userspace. What functionality does this provide on a
On Mon, 15 Aug 2005 18:38:49 CDT, Doug Warzecha said:
If this is supposed to be used with the RBU code to trigger a BIOS
update, ...
This driver is not needed by the RBU code.
Documentation/dell_rbu.txt says:
The rbu driver needs to have an application which will inform the BIOS to
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
Why can't you just implement the system management actions in the
kernel driver?
Why put things in the kernel unless it's really needed?
I'm not thrillied about the lack of userspace support for this driver
but that still doesn't
On Aug 16, 2005, at 00:34:51, Chris Wedgwood wrote:
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
Why can't you just implement the system management actions in the
kernel driver?
Why put things in the kernel unless it's really needed?
I'm not thrillied about the lack of
I am not subscribed to linux-kernel. Please cc me (and Doug) on all
replies. Sorry if I'm breaking peoples threading, but I am cut-and-
pasting this from web archives, since this wasn't cc-d to me
originally.
On Aug 15, 2005, at 19:38:49, Doug Warzecha wrote:
On Mon, Aug 15, 2005 at 04:23:37PM
On Tue, Aug 16, 2005 at 12:55:35AM -0400, Kyle Moffett wrote:
I'm worried that it might be more of a mess in userspace than it
could be if done properly in the kernel.
I would rather if it's gonna be a mess it's, then we put that mess in
userspace rather than in the kernel.
Hardware drivers,
On Mon, 15 Aug 2005 23:09:28 CDT, you said:
No, dcdbas has nothing to do with this. I'll have to submit a patch
against the docs. The program you need to use already exists and is
open source. You can use libsmbios to do this.
http://linux.dell.com/libsmbios/main.
Now I'm confoozled. Maybe
Again, please cc Doug and I on replies...
Kyle Moffett wrote:
On Aug 16, 2005, at 00:34:51, Chris Wedgwood wrote:
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
Why can't you just implement the system management actions in the
kernel driver?
Why put things in the kernel unless
On Tue, 2005-08-16 at 01:17 -0400, [EMAIL PROTECTED] wrote:
On Mon, 15 Aug 2005 23:09:28 CDT, you said:
No, dcdbas has nothing to do with this. I'll have to submit a patch
against the docs. The program you need to use already exists and is
open source. You can use libsmbios to do this.
On Tue, Aug 16, 2005 at 12:19:49AM -0500, Michael E Brown wrote:
Hmm... did I mention libsmbios? :-)
http://linux.dell.com/libsmbios/main.
I'm aware of it --- it seems pretty limited right now and I'm still
irked Dell isn't more forthcoming with documentation.
SMI support is not yet
On Mon, 15 Aug 2005 23:58:43 CDT, Michael E Brown said:
No, this is an _EXCELLENT_ reason why _LESS_ of this should be in the
kernel. Why should we have to duplicate a _TON_ of code inside the
kernel to figure out which platform we are on, and then look up in a
table which method to use for
On Mon, 2005-08-15 at 22:35 -0700, Chris Wedgwood wrote:
On Tue, Aug 16, 2005 at 12:19:49AM -0500, Michael E Brown wrote:
Hmm... did I mention libsmbios? :-)
http://linux.dell.com/libsmbios/main.
I'm aware of it --- it seems pretty limited right now and I'm still
irked Dell isn't more
72 matches
Mail list logo
