RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Grover, Andrew]

> From: David Brownell [mailto:david-b@pacbell.net] 
> > Is the device PHYSICALLY hooked up to the computer? If not, 
> it shouldn't be
> > in devicefs.
> What's "devicefs" -- some new filesystem?  Or a mis/re-naming 
> of "driverfs"?
> I assume you don't mean "devfs".

Yep I meant driverfs. Oops.

> > The device tree (for which devicefs is the fs 
> representation) was originally
> > meant to enable good device power management and configuration. 
> 
> Surely a driver using IP-over-wire like iSCSI is no less 
> deserving of appearing
> in "driverfs" than one whose driver uses 
> custom-protocol-over-a-"wire" like USB,
> FireWire, FC, IR, SCSI, or Bluetooth?  I don't see why some 
> disks (for example)
> should deserve to be "more equal than others" -- and approved 
> to be in driverfs.

It's a matter of where to draw the line. Obviously when we're talking
physical devices, my tcpip connection to www.yahoo.com is not one. My PS/2
port is. I actually think keeping in mind that driverfs is for power
management can help delineate what should be in driverfs and what shouldn't.
With technologies like USB, infiniband, NFS, iSCSI, and 1394, it's tough,
but the main question should be:

"If my computer suspends, should this device be turned off?" Which is
another way of asking is the use of a device exclusive to a particular
machine.

If a device can be accessed by multiple machines concurrently, it should not
be in driverfs.

> No, of course driverfs isn't for everything.  But if it's not 
> for all drivers,
> then what's it for -- just power management?

"Just" power management??? Like power management isn't important enough???
;-)

We need a device tree to do PM. If driverfs's PM capabilities are hurt
because it doesn't stay true to that, then the featureitis has gone too far.

Regards -- Andy

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map

[kernel]

> It's a matter of where to draw the line. Obviously when we're talking
> physical devices, my tcpip connection to www.yahoo.com is not one. My PS/2
> port is. I actually think keeping in mind that driverfs is for power
> management can help delineate what should be in driverfs and what shouldn't.
> With technologies like USB, infiniband, NFS, iSCSI, and 1394, it's tough,
> but the main question should be:
> 
> "If my computer suspends, should this device be turned off?" Which is
> another way of asking is the use of a device exclusive to a particular
> machine.
> 
> If a device can be accessed by multiple machines concurrently, it should not
> be in driverfs.

That is rather confusing with respect to 1394. You should log out of sbp2
devices, but they can still be shared. Basically 1394 is shared though, and
other types of device dont have logins. So you should probably exclude it.
But anything with disks on at least wants the device flushed before sleeping,
and probably unmounted in many cases.

Justin

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[David Brownell]

>>No, of course driverfs isn't for everything.  But if it's not 
>>for all drivers,
>>then what's it for -- just power management?
>  
> "Just" power management??? Like power management isn't important enough???
> ;-)

Well, it's only one of the roles I'd expect of a "driver filesystem",
and actually no -- not the most important one.  If instead it were
called "powermanagementfs" ... or if it were renamed to that ... :)


> We need a device tree to do PM. If driverfs's PM capabilities are hurt
> because it doesn't stay true to that, then the featureitis has gone too far.

And for other reasons, we also need one.  I don't think you've actually
pointed out any concrete problems for PM though.

- Dave

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[David Brownell]

>>No, of course driverfs isn't for everything.  But if it's not 
>>for all drivers,
>>then what's it for -- just power management?
>  
> "Just" power management??? Like power management isn't important enough???
> ;-)

Well, it's only one of the roles I'd expect of a "driver filesystem",
and actually no -- not the most important one.  If instead it were
called "powermanagementfs" ... or if it were renamed to that ... :)


> We need a device tree to do PM. If driverfs's PM capabilities are hurt
> because it doesn't stay true to that, then the featureitis has gone too far.

And for other reasons, we also need one.  I don't think you've actually
pointed out any concrete problems for PM though.

- Dave

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[James Bottomley]

andrew.grover@intel.com said:
> If a device can be accessed by multiple machines concurrently, it
> should not be in driverfs. 

On that argument, we'll eliminate almost all Fibre Channel devices!

I think the qualification for appearing in driverfs is actually possessing a 
driver.  Therefore, we accept FC and iSCSI.  Things which appear as 
FileSystems are debatable, but not anything which has a real device driver.

> We need a device tree to do PM. If driverfs's PM capabilities are hurt
> because it doesn't stay true to that, then the featureitis has gone
> too far. 

Perhaps it's more a question of whether power management belongs as an every 
unit item in driverfs.  As you say, we get problems where the device is shared 
between multiple computers.

James

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Oliver Xymoron]

On Mon, 24 Jun 2002, James Bottomley wrote:

> andrew.grover@intel.com said:
> > If a device can be accessed by multiple machines concurrently, it
> > should not be in driverfs.
>
> On that argument, we'll eliminate almost all Fibre Channel devices!
>
> I think the qualification for appearing in driverfs is actually possessing a
> driver.  Therefore, we accept FC and iSCSI.  Things which appear as
> FileSystems are debatable, but not anything which has a real device driver.

Between iSCSI and filesystems there's still MD, loopback, ramdisk, NBD,
LVM, and general partitioning. They all expose block devices and try their
damnedest to look like physical devices. If we're serious about using
driverfs as a system for unifying device detection ("show me all my disks,
please"), then these should all be in too.

And they raise some interesting problems. As pointed out earlier, iSCSI is
potentially multipath, as is LVM, NBD, and software RAID. Hardware RAID is
already multipath in some cases so our tree really ought to be a DAG.

And let's think about loopback a moment. It's potentially layered on top
of a filesystem, layered on top of a logical volume layered on top of SCSI
and ATA. Just from the power management perspective, to quiesce our
system, we'll have to know that we need to flush loop->fs->lvm->scsi/ata
before we can shut down whichever drive.

So to be done right, we need to pull filesystems into the tree too (rather
than just implicitly correlating against /proc/mounts).

> > We need a device tree to do PM. If driverfs's PM capabilities are hurt
> > because it doesn't stay true to that, then the featureitis has gone
> > too far.
>
> Perhaps it's more a question of whether power management belongs as an every
> unit item in driverfs.  As you say, we get problems where the device is shared
> between multiple computers.

And we already have a problem there for local SCSI - see OpenGFS which
lets you share a filesystem on a single SCSI bus. Admittedly, that's
rather sick, but not as appalling for FC, iSCSI, or NBD (or GFS's
internal equivalent).

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Oliver Xymoron]

On Mon, 24 Jun 2002, James Bottomley wrote:

> andrew.grover@intel.com said:
> > If a device can be accessed by multiple machines concurrently, it
> > should not be in driverfs.
>
> On that argument, we'll eliminate almost all Fibre Channel devices!
>
> I think the qualification for appearing in driverfs is actually possessing a
> driver.  Therefore, we accept FC and iSCSI.  Things which appear as
> FileSystems are debatable, but not anything which has a real device driver.

Between iSCSI and filesystems there's still MD, loopback, ramdisk, NBD,
LVM, and general partitioning. They all expose block devices and try their
damnedest to look like physical devices. If we're serious about using
driverfs as a system for unifying device detection ("show me all my disks,
please"), then these should all be in too.

And they raise some interesting problems. As pointed out earlier, iSCSI is
potentially multipath, as is LVM, NBD, and software RAID. Hardware RAID is
already multipath in some cases so our tree really ought to be a DAG.

And let's think about loopback a moment. It's potentially layered on top
of a filesystem, layered on top of a logical volume layered on top of SCSI
and ATA. Just from the power management perspective, to quiesce our
system, we'll have to know that we need to flush loop->fs->lvm->scsi/ata
before we can shut down whichever drive.

So to be done right, we need to pull filesystems into the tree too (rather
than just implicitly correlating against /proc/mounts).

> > We need a device tree to do PM. If driverfs's PM capabilities are hurt
> > because it doesn't stay true to that, then the featureitis has gone
> > too far.
>
> Perhaps it's more a question of whether power management belongs as an every
> unit item in driverfs.  As you say, we get problems where the device is shared
> between multiple computers.

And we already have a problem there for local SCSI - see OpenGFS which
lets you share a filesystem on a single SCSI bus. Admittedly, that's
rather sick, but not as appalling for FC, iSCSI, or NBD (or GFS's
internal equivalent).

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Patrick Mochel]

> I think the qualification for appearing in driverfs is actually possessing a 
> driver.  Therefore, we accept FC and iSCSI.  Things which appear as 
> FileSystems are debatable, but not anything which has a real device driver.

The qualification for appearing in the device tree is the physical 
presence of the device, regardless of the presence of a driver to control 
it. (This typically depends on the presence of the bus driver so it can 
discover the device.) Presence in the device tree implies presence in 
driverfs.

	-pat

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Patrick Mochel]

> I think the qualification for appearing in driverfs is actually possessing a 
> driver.  Therefore, we accept FC and iSCSI.  Things which appear as 
> FileSystems are debatable, but not anything which has a real device driver.

The qualification for appearing in the device tree is the physical 
presence of the device, regardless of the presence of a driver to control 
it. (This typically depends on the presence of the bus driver so it can 
discover the device.) Presence in the device tree implies presence in 
driverfs.

	-pat

RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Roman Zippel]

Hi,

On Mon, 24 Jun 2002, Grover, Andrew wrote:

> With technologies like USB, infiniband, NFS, iSCSI, and 1394, it's tough,
> but the main question should be:
>
> "If my computer suspends, should this device be turned off?" Which is
> another way of asking is the use of a device exclusive to a particular
> machine.
>
> If a device can be accessed by multiple machines concurrently, it should not
> be in driverfs.

I don't think it's that easy. If the computer wakes up again, devices have
to be reinitialised in the right order, e.g. iSCSI needs a working network
stack and devices. Another problem is how to properly shutdown the
machine. Scripts now "know" that nfs requires the network, but how does
the script find out, that /dev/sdb2 is an iSCSI device, so that it can
properly unmount the device, before the network is shutdown?

bye, Roman

RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Roman Zippel]

Hi,

On Mon, 24 Jun 2002, Grover, Andrew wrote:

> With technologies like USB, infiniband, NFS, iSCSI, and 1394, it's tough,
> but the main question should be:
>
> "If my computer suspends, should this device be turned off?" Which is
> another way of asking is the use of a device exclusive to a particular
> machine.
>
> If a device can be accessed by multiple machines concurrently, it should not
> be in driverfs.

I don't think it's that easy. If the computer wakes up again, devices have
to be reinitialised in the right order, e.g. iSCSI needs a working network
stack and devices. Another problem is how to properly shutdown the
machine. Scripts now "know" that nfs requires the network, but how does
the script find out, that /dev/sdb2 is an iSCSI device, so that it can
properly unmount the device, before the network is shutdown?

bye, Roman

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[John Summerfield]

> 
> It's a matter of where to draw the line. Obviously when we're talking
> physical devices, my tcpip connection to www.yahoo.com is not one. My PS/2

I'm far from expert here, but isn't the network card important here?


> 
> If a device can be accessed by multiple machines concurrently, it should not
> be in driverfs.
> 

Back in the 1970s I used a computer where disk drives, tape drives and RAM 
chould be physically connected to and used by more than one computer at once.

It was an IBM S/370 model 168 MP; you might argue the toss on the RAM, but the 
disk drives were beyond argument.


On which devices should MVS have ignored power cycling?
-- 
Cheers
John Summerfield

Microsoft's most solid OS: http://www.geocities.com/rcwoolley/

Note: mail delivered to me is deemed to be intended for me, for my disposition.

==============================
If you don't like being told you're wrong,
	be right!

RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Patrick Mochel]

> > Surely a driver using IP-over-wire like iSCSI is no less 
> > deserving of appearing
> > in "driverfs" than one whose driver uses 
> > custom-protocol-over-a-"wire" like USB,
> > FireWire, FC, IR, SCSI, or Bluetooth?  I don't see why some 
> > disks (for example)
> > should deserve to be "more equal than others" -- and approved 
> > to be in driverfs.
> 
> It's a matter of where to draw the line. Obviously when we're talking
> physical devices, my tcpip connection to www.yahoo.com is not one. My PS/2
> port is. I actually think keeping in mind that driverfs is for power
> management can help delineate what should be in driverfs and what shouldn't.
> With technologies like USB, infiniband, NFS, iSCSI, and 1394, it's tough,
> but the main question should be:

When you're talking to www.yahoo.com, you're really only talking to the 
webserver. Sure, indirectly you're talking to their network card, their 
disk, their memory, and their cpu. But, let's not get carried away. 

With things like network block devices, you're communicating directly with 
a device. (Yes, it may be a virtual device that doesn't have a mapping to 
a real physical device. But it doesn't matter; you _think_ it's a device.)

driverfs is not power management. driverfs does not care about power 
management. The device model is not about power management. Power 
management is one benefit of having a unified device tree, but it is not 
it's main focus. It's purpose is to represent the physical layout of 
devices in the system as accurately as possible. 

> "If my computer suspends, should this device be turned off?" Which is
> another way of asking is the use of a device exclusive to a particular
> machine.
> 
> If a device can be accessed by multiple machines concurrently, it should not
> be in driverfs.

So, what about network cards? Disks with partitions exported via NFS? 
Serial ports with a null modem attached? 

Sound absurd? Of course it does, but in it lies the distinction between 
devices you care about and devices you don't: if it's local, you suspend 
it. If it's not, then you don't power it down. The drivers for these 
devices should be able to tell whether you're communicating with a local 
or remote device and choose the appropriate action. 

	-pat

RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Patrick Mochel]

> > Surely a driver using IP-over-wire like iSCSI is no less 
> > deserving of appearing
> > in "driverfs" than one whose driver uses 
> > custom-protocol-over-a-"wire" like USB,
> > FireWire, FC, IR, SCSI, or Bluetooth?  I don't see why some 
> > disks (for example)
> > should deserve to be "more equal than others" -- and approved 
> > to be in driverfs.
> 
> It's a matter of where to draw the line. Obviously when we're talking
> physical devices, my tcpip connection to www.yahoo.com is not one. My PS/2
> port is. I actually think keeping in mind that driverfs is for power
> management can help delineate what should be in driverfs and what shouldn't.
> With technologies like USB, infiniband, NFS, iSCSI, and 1394, it's tough,
> but the main question should be:

When you're talking to www.yahoo.com, you're really only talking to the 
webserver. Sure, indirectly you're talking to their network card, their 
disk, their memory, and their cpu. But, let's not get carried away. 

With things like network block devices, you're communicating directly with 
a device. (Yes, it may be a virtual device that doesn't have a mapping to 
a real physical device. But it doesn't matter; you _think_ it's a device.)

driverfs is not power management. driverfs does not care about power 
management. The device model is not about power management. Power 
management is one benefit of having a unified device tree, but it is not 
it's main focus. It's purpose is to represent the physical layout of 
devices in the system as accurately as possible. 

> "If my computer suspends, should this device be turned off?" Which is
> another way of asking is the use of a device exclusive to a particular
> machine.
> 
> If a device can be accessed by multiple machines concurrently, it should not
> be in driverfs.

So, what about network cards? Disks with partitions exported via NFS? 
Serial ports with a null modem attached? 

Sound absurd? Of course it does, but in it lies the distinction between 
devices you care about and devices you don't: if it's local, you suspend 
it. If it's not, then you don't power it down. The drivers for these 
devices should be able to tell whether you're communicating with a local 
or remote device and choose the appropriate action. 

	-pat

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Pavel Machek]

Hi!

> If a device can be accessed by multiple machines concurrently, it should not
> be in driverfs.

You can access scsi disk from 2 machines simultaneously. Its just not
a common case. I believe we still want scsi in driverfs ;-).
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: Runlevel for Sleep?

[Lyle Seaman]

> I think we'll know better once we have working device power management if a
> new runlevel is needed or not.

I'll second this.  It seems that everybody is spending time fiddling with 
workarounds instead of fixing the drivers.

Personally, I'm trying to get the e1000 driver to resume correctly. 
After resume, an ifconfig down, ifconfig up cycle works fine, so it can't be 
*that* hard.  But my naive approach (run the down and up methods) doesn't do 
the trick, nor does merely running the close and open methods.

The analysis is complicated by the fact that the e1000 driver must be compiled 
as a module, and debugging modules with kgdb is a bit sketchy, and setting a 
breakpoint within the resume function always makes it segfault ... :(





-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Runlevel for Sleep?

[P. Christeas]

Grover, Andrew wrote:
> > From: P. Christeas [mailto:p_christ-U04EIuiosng@public.gmane.org]
> > It has just come up to me, should we use a runlevel for sleep?
>
> Right now I am leaning towards no. We don't have a runlevel for APM's
> suspend, why would we for ACPI sleep?
>
> Sleep should be very quick to enter and exit. We shouldn't have to shut
> down any services. If the drivers properly save and restore context, things
> on resume should just pick up where they left off.
>
> I think we'll know better once we have working device power management if a
> new runlevel is needed or not.
>
> Regards -- Andy

I think we already have a working power device management, thanks for that!
The mail I sent only reflects my humble opinion, I just ask if it's time we 
thought of such a change.

APM suspend never worked for me and I guess that anybody that managed to use 
it has used workarounds. ACPI already is much better than that.

We may never have 100% bug-free drivers, some of them will always need 
workarounds.
In the other hand, hardware is not the only matter. The ethernet card may not 
have any trouble at all sleeping. The net behind it, however, may change much 
while our box is sleeping. What if we have clients connected and shouldn't 
sleep after all? Now, it's up to the person pressing the 'sleep' button to 
take care of such issues. I prefer everything to be automated.

IMHO it shouldn't matter how long sleep needs to enter or exit. After all, 
initscripts won't necessarily mean that the system will be loaded 
significantly. I like binaries to keep small, as we have them loaded all the 
time. So, why have all the resume code inside the kernel, while we can only 
call a few binaries to resume?

Here is what I suggest [flame bait] :

sleep button/command
||
V
'init 7' event
||
V
initscripts like 'netfs suspend' etc. The initscrips are allowed to fail 
(say, a client on httpd) => return to previous runlevel
|
v
on sucess => 'echo 1/3/4 > /proc/acpi/sleep' by the inittab

sleeping... wake event => we're leaving runlevel 7 => restore suspended 
services with 'netfs resume' and use workarounds for buggy drivers like 
'bugcard restore' etc.
||
V
our system is ready.





-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Charl P. Botha]

On Wed, Sep 04, 2002 at 01:50:57PM +0300, P. Christeas wrote:
> Here is what I suggest [flame bait] :
> 
> sleep button/command
> ||
> V
> 'init 7' event
> ||
> V
> initscripts like 'netfs suspend' etc. The initscrips are allowed to fail 
> (say, a client on httpd) => return to previous runlevel
> |
> v
> on sucess => 'echo 1/3/4 > /proc/acpi/sleep' by the inittab
> 
> sleeping... wake event => we're leaving runlevel 7 => restore suspended 
> services with 'netfs resume' and use workarounds for buggy drivers like 
> 'bugcard restore' etc.
> ||
> V
> our system is ready.

What's wrong with using user-defined acpid hooks for ACPI events?  This
works now... there's nothing stopping you from making your own runlevels and
invoking them from the acpid hooks yourself.

My 2c,
Charl

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Robert Wo"rle]

P. Christeas schrieb:

>Grover, Andrew wrote:
>  
>
>>>From: P. Christeas [mailto:p_christ-U04EIuiosng@public.gmane.org]
>>>It has just come up to me, should we use a runlevel for sleep?
>>>      
>>>
>>Right now I am leaning towards no. We don't have a runlevel for APM's
>>suspend, why would we for ACPI sleep?
>>
>>Sleep should be very quick to enter and exit. We shouldn't have to shut
>>down any services. If the drivers properly save and restore context, things
>>on resume should just pick up where they left off.
>>
>>I think we'll know better once we have working device power management if a
>>new runlevel is needed or not.
>>
>>Regards -- Andy
>>    
>>
>
>I think we already have a working power device management, thanks for that!
>The mail I sent only reflects my humble opinion, I just ask if it's time we 
>thought of such a change.
>
>APM suspend never worked for me and I guess that anybody that managed to use 
>it has used workarounds. ACPI already is much better than that.
>  
>
Well i had a working APM , but i also had to use the magic apmd_proxy 
script where i placed the scripts to start and stop the critical things 
( for me it was _USB and pcmcia )
So why dont we think about something similar so a script where ACPI 
looks for at States and do the things which supposed to be done ...

>We may never have 100% bug-free drivers, some of them will always need 
>workarounds.
>In the other hand, hardware is not the only matter. The ethernet card may not 
>have any trouble at all sleeping. The net behind it, however, may change much 
>while our box is sleeping. What if we have clients connected and shouldn't 
>sleep after all? Now, it's up to the person pressing the 'sleep' button to 
>take care of such issues. I prefer everything to be automated.
>
>IMHO it shouldn't matter how long sleep needs to enter or exit. After all, 
>initscripts won't necessarily mean that the system will be loaded 
>significantly. I like binaries to keep small, as we have them loaded all the 
>time. So, why have all the resume code inside the kernel, while we can only 
>call a few binaries to resume?
>
>Here is what I suggest [flame bait] :
>
>sleep button/command
>||
>V
>'init 7' event
>||
>V
>initscripts like 'netfs suspend' etc. The initscrips are allowed to fail 
>(say, a client on httpd) => return to previous runlevel
>|
>v
>on sucess => 'echo 1/3/4 > /proc/acpi/sleep' by the inittab
>
>sleeping... wake event => we're leaving runlevel 7 => restore suspended 
>services with 'netfs resume' and use workarounds for buggy drivers like 
>'bugcard restore' etc.
>||
>V
>our system is ready.
>
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: OSDN - Tired of that same old
>cell phone?  Get a new here for FREE!
>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>_______________________________________________
>Acpi-devel mailing list
>Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>https://lists.sourceforge.net/lists/listinfo/acpi-devel
>
>
>  
>

-- 
_____________________________________
*Robert Wo"rle
Linux | Embedded Device*
*
Symplon AG*

*...touch the internet*

phone: +49 89 552 999 35
fax: +49 89 552 999 10
email: robert.woerle-y2s3ugBAdl9BDgjK7y7TUQ@public.gmane.org <mailto:robert.woerle@symplon.com>
web: www.symplon.com <http://www.symplon.com/>

_____________________________________




-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Pavel Machek]

Hi!

> Right now I am leaning towards no. We don't have a runlevel for APM's
> suspend, why would we for ACPI sleep?

I believe we should have it for APM, too.

umounting nfs seems like good idea, and no ammount of drivers will fix that.

> I think we'll know better once we have working device power management if a
> new runlevel is needed or not.

I believe 3 of them are needed - S1, S3 and S4. 
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Patrick Mochel]

On Fri, 6 Sep 2002, Pavel Machek wrote:

> Hi!
> 
> > Right now I am leaning towards no. We don't have a runlevel for APM's
> > suspend, why would we for ACPI sleep?
> 
> I believe we should have it for APM, too.
> 
> umounting nfs seems like good idea, and no ammount of drivers will fix that.
>
> > I think we'll know better once we have working device power management if a
> > new runlevel is needed or not.
> 
> I believe 3 of them are needed - S1, S3 and S4. 

I agree that we need to do some amount of user-level work before we go to 
sleep, but I'm not sure that a runlevel is the proper way to implement it. 

Unless you implemented a new runlevel for every possible sleep state for 
every possible platform suspend mechanism, how would pass what suspend 
state you wanted to enter? 

You don't really want to have a different one for S1, S3, and S4 because 
they are ACPI specific, both in terms of their names and what they mean. 
I don't think you could create a clean, sensible solution like that, that 
worked for all platforms...

You could have one runlevel, and pass the state we're entering somehow. 
But, we would need to get that from init(8) to reboot(2) [1]. That way we 
could use standard rc scripts for doing all the dirty little things we 
need to before we sleep. 

	-pat

[1] Once upon a time (last May), I implemented a patch that overloaded the
reboot(2) system call to initiate suspend transitions in a
platform-specific manner (as per Linus's suggestion). This is in the
resurrection queue and will probably resurface soon. 

This allows every platform to use the same mechanism for suspending. Of 
course some suspend states are platform-specific, but a few are generic 
(suspend to ram, suspend to disk). The userspace caller would pass the 
platform-specific state. sys_reboot() simply passes that on to the 
platform-supplied callback..





-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Pavel Machek]

Hi!

> > I believe 3 of them are needed - S1, S3 and S4. 
> 
> I agree that we need to do some amount of user-level work before we go to 
> sleep, but I'm not sure that a runlevel is the proper way to implement it. 
> 
> Unless you implemented a new runlevel for every possible sleep state for 
> every possible platform suspend mechanism, how would pass what suspend 
> state you wanted to enter? 
> 
> You don't really want to have a different one for S1, S3, and S4 because 
> they are ACPI specific, both in terms of their names and what they mean. 
> I don't think you could create a clean, sensible solution like that, that 
> worked for all platforms...

Okay, we can probably forget S1 and create arch-neutral
"suspend-to-disk" and "suspend-to-ram".

I'm not 100% sure runlevels are the right way, but they certainly look
better than special-purpose script.

...and we already have one for halt, which is just S5....

> You could have one runlevel, and pass the state we're entering somehow. 
> But, we would need to get that from init(8) to reboot(2) [1]. That way we 
> could use standard rc scripts for doing all the dirty little things we 
> need to before we sleep. 
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[P. Christeas]

> Hi!
>
> > > I believe 3 of them are needed - S1, S3 and S4.
> >
It might be, but that way we are reserving all unimplemented runlevels, which 
looks really bad. I wish we could safely (for all systems) pass sth like an 
argument to the runlevel, indicating which sleep state we 're getting into.

> > I agree that we need to do some amount of user-level work before we go to
> > sleep, but I'm not sure that a runlevel is the proper way to implement
> > it.
My "original" idea is to use the init mechanism instead of any custom scripts 
and code, mainly just to avoid having extra binaries in our kernel.

> >
> > Unless you implemented a new runlevel for every possible sleep state for
> > every possible platform suspend mechanism, how would pass what suspend
> > state you wanted to enter?

If you do that, you're certainly ACPI-specific.

> >
> > You don't really want to have a different one for S1, S3, and S4 because
> > they are ACPI specific, both in terms of their names and what they mean.
> > I don't think you could create a clean, sensible solution like that, that
> > worked for all platforms...
>
> Okay, we can probably forget S1 and create arch-neutral
> "suspend-to-disk" and "suspend-to-ram".
>

IMHO you couldn't skip S1. I'm using that (in fact S3 works for me much 
worse) and I surely have to run some scripts before entering that.

We could easily agree with APM developers to have a common implementation, 
which gives the runlevel implementation an advantage. The runlevel business 
should not be ACPI specific for sure.

P. Christeas


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Stephen L Johnson]

On Fri, 2002-09-06 at 16:40, Patrick Mochel wrote:
> 
> On Fri, 6 Sep 2002, Pavel Machek wrote:
> 
> > Hi!
> > 
> > > Right now I am leaning towards no. We don't have a runlevel for APM's
> > > suspend, why would we for ACPI sleep?
> > 
> > I believe we should have it for APM, too.
> > 
> > umounting nfs seems like good idea, and no ammount of drivers will fix that.
> >
> > > I think we'll know better once we have working device power management if a
> > > new runlevel is needed or not.
> > 
> > I believe 3 of them are needed - S1, S3 and S4. 
> 
> I agree that we need to do some amount of user-level work before we go to 
> sleep, but I'm not sure that a runlevel is the proper way to implement it. 
> 
> Unless you implemented a new runlevel for every possible sleep state for 
> every possible platform suspend mechanism, how would pass what suspend 
> state you wanted to enter? 
> 
> You don't really want to have a different one for S1, S3, and S4 because 
> they are ACPI specific, both in terms of their names and what they mean. 
> I don't think you could create a clean, sensible solution like that, that 
> worked for all platforms...
> 
> You could have one runlevel, and pass the state we're entering somehow. 
> But, we would need to get that from init(8) to reboot(2) [1]. That way we 
> could use standard rc scripts for doing all the dirty little things we 
> need to before we sleep. 
> 

Hi all. I'm new to the list.

I've been involved with the Linux on PDAs/handheld computers over at
http://www.handhelds.org/. They have to deal with the exact same issues
suspend/resumes issues with drivers and user-space issues. Although they
major concern is just with suspending in memory.

Over the past several versions of Familiar (a linux distrubution for
handhelds) a method for dealing with user space suspend and resume
issues have been developer. It is working quite well. 

The kernel calls a user space program called pmhelper with a "suspend"
or "resume" parameter. On a suspend, pmhelper is called before the
kernel  suspends the drivers. And on a resume it's called after the
kernel resumes the drivers. 

The pmhelper program on familiar calls a series of scripts in
/etc/suspend-scripts/ or /etc/resume-scripts/ (depending on the pending
state). The scripts are run in a SysV boot-script way. The scripts are
named nnScriptName where nn are numbers. 

I'm sure that this pmhelper/scripts method could easily be adapted for
ACPI/APM usage. Just my .02 cent.

--
Stephe L Johnson <sjohnson-WpdXj7kV/NVg9hUCZPvPmw@public.gmane.org>




-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Patrick Mochel]

On 7 Sep 2002, Stephen L Johnson wrote:

> I've been involved with the Linux on PDAs/handheld computers over at
> http://www.handhelds.org/. They have to deal with the exact same issues
> suspend/resumes issues with drivers and user-space issues. Although they
> major concern is just with suspending in memory.
> 
> Over the past several versions of Familiar (a linux distrubution for
> handhelds) a method for dealing with user space suspend and resume
> issues have been developer. It is working quite well. 
> 
> The kernel calls a user space program called pmhelper with a "suspend"
> or "resume" parameter. On a suspend, pmhelper is called before the
> kernel  suspends the drivers. And on a resume it's called after the
> kernel resumes the drivers. 

That's not bad, but I see two problems:

- The suspend transition is usually initiated from user input, i.e. 
userspace. So, userspace would be calling into the kernel, which would be 
calling back to userspace, and returning back to the kernel to finish it 
up. 

It seems much easier to do the work you need in userspace, then transfer 
control over to the kernel once and for all.

- The standard mechanism for calling into userspace is /sbin/hotplug. 
There is NWIH you'll be able to sneak another mechanism into the kernel. 
So, being stuck with /sbin/hotplug, you run into the problem that it 
executes asynchronously. You want to wait for the userspace stuff to 
finish before you continue suspending, so you'd have to add yet more code 
to wait for notification from userspace...

> The pmhelper program on familiar calls a series of scripts in
> /etc/suspend-scripts/ or /etc/resume-scripts/ (depending on the pending
> state). The scripts are run in a SysV boot-script way. The scripts are
> named nnScriptName where nn are numbers. 

For Midori Linux (a distro for the all-but-dead x86 internet appliance
market), we rewrote the init script hoo-haw to be similar to this thing
called simpleinit. (A dependency graph was constructed so we could execute
the init scripts in parallel). Suspend was initiated via a GUI or script, 
which triggered init to run, passing 'suspend' to all the init scripts 
(and 'resume' on Resume).

In essence, we're going to be doing something similar. It's just a matter 
of how we articulate it. Also, remember that we must do the converse 
action on resume (call all the init scripts again). But, is that really a 
runlevel transition? We'd be transferring back from 7 (or whatever) to 3 
or 5. But, we don't want to restart everything; only the stuff that we 
suspended.

Are there any ideas from some of the older-school people? How exactly does 
APM do it? 


	-pat



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[P. Christeas]

Patrick Mochel wrote:
> In essence, we're going to be doing something similar. It's just a matter
> of how we articulate it. Also, remember that we must do the converse
> action on resume (call all the init scripts again). But, is that really a
> runlevel transition? We'd be transferring back from 7 (or whatever) to 3
> or 5. But, we don't want to restart everything; only the stuff that we
> suspended.

Right, on resume we sould only call the scripts that "leave rl. 7", not the 
ones that enter 3 or 5. This is tricky (in concept). Moreover, I had 
recommended that the initscripts introduce the words "suspend" and "resume" 
instead of "stop" and "start". This way, we could partially suspend a service.
For example, a network daemon should drop all active connections when 
suspended, but not die itself (as in 'stop'). It could keep listening to a 
port.
One more thing  (as Lyle Seaman has pointed out) is that sometimes we don't 
want to suspend, even though the user has pressed the 'suspend button'. This 
means that the initscripts should be allowed to fail, in a manner such that 
the sleep state will not be eventually entered.


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Diego Zuccato]

"P. Christeas" wrote:
> Right, on resume we sould only call the scripts that "leave rl. 7", not the
> ones that enter 3 or 5. This is tricky (in concept). Moreover, I had
> recommended that the initscripts introduce the words "suspend" and "resume"
> instead of "stop" and "start". This way, we could partially suspend a service.
> For example, a network daemon should drop all active connections when
> suspended, but not die itself (as in 'stop'). It could keep listening to a
> port.
Why ???
If you need that daemon to terminate answering pending connections, then
use stop. If you don't (e.g. there is no timeout on the other side),
then simply leave it alone. Really, you don't want it to accept more
connections. What happens if you are suspending a db server (well,
suspending a server is IMHO a really stupid thing, but...) and after
giving it "suspend" a new connection request arrives ? It can only be
discarded (then stop the service...) or accepted (so why in the hell is
"suspend" needed???).

Just my .02 ...

BYtE,
 Diego.


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[P. Christeas]

Diego Zuccato wrote:
> "P. Christeas" wrote:
> > Right, on resume we sould only call the scripts that "leave rl. 7", not
> > the ones that enter 3 or 5. This is tricky (in concept). Moreover, I had
> > recommended that the initscripts introduce the words "suspend" and
> > "resume" instead of "stop" and "start". This way, we could partially
> > suspend a service. For example, a network daemon should drop all active
> > connections when suspended, but not die itself (as in 'stop'). It could
> > keep listening to a port.
>
> Why ???
> If you need that daemon to terminate answering pending connections, then
> use stop. If you don't (e.g. there is no timeout on the other side),
> then simply leave it alone. Really, you don't want it to accept more
> connections. What happens if you are suspending a db server (well,
> suspending a server is IMHO a really stupid thing, but...) and after
> giving it "suspend" a new connection request arrives ? It can only be
> discarded (then stop the service...) or accepted (so why in the hell is
> "suspend" needed???).
>
> Just my .02 ...
>
> BYtE,
>  Diego.

The whole point of the initscripts is that this is your call. The kernel 
provides the functionality and you (as the root of the system) are free to 
write any script you feel like doing.
I have suggested the 'suspend/resume' extensions because they might solve a 
few problems for *some* services. For example, you may want to stop serving 
connections, but restarting the service (the old way) may require such time, 
that the sleep/wake operation would take long (and you may not want that).
One more point is that some services may want to be notified that the system 
is going to sleep, even if they do practically nothing about it.
We are not going to handle all cases at the first day of this implementation. 
I just try to imagine situations thay may need design consideration.

P.Christeas 


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Diego Zuccato]

"P. Christeas" wrote:

> The whole point of the initscripts is that this is your call. The kernel
[...]
> I just try to imagine situations thay may need design consideration.
Uhm... Then just call your scripts from acpid. Or manage yourself ACPI
events. It's all in userspace. If a service needs special handling,
simply do it before (suspend) or after (resume) echoing to
/proc/acpi/sleep. IMO there's no need to provide extra hooks.
The timer setting, IIRC, is one of the "services" that need that kind of
special handlin (at resume, you have to set current time from hw clock).
Think echoing to /proc/scpi/sleep as a REALLY slow ATOMIC operation :-)

BYtE,
 Diego.


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Pavel Machek]

Hi!

> connections. What happens if you are suspending a db server (well,
> suspending a server is IMHO a really stupid thing, but...) and after

Why?

You bought new UPS for your server. How do you install it without
bringing machine down? Suspend to disk, rearrange power cables,
resume.

You have your server on UPS. Power died, and UPS is indicating 30
seconds to failure. What do you do? Suspend to disk.

Ethernet card in your server died. You want to replace it. Your
server is not hotplug capable. What do you do? Suspend to disk,
replace ethernet card, resume. If you are fast your users will not
even see broken connections.

[I've created FAQ section in Documentation/swsusp.txt; I'll put this
question/answer in there in next merge.]
								Pavel

-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Runlevel for Sleep?

[Andreas Lohrum]

Pavel Machek <pavel=AlSwsSmVLrQ@public.gmane.org> writes:

> Hi!
> 
> > connections. What happens if you are suspending a db server (well,
> > suspending a server is IMHO a really stupid thing, but...) and after
> 
> Why?
> 
> You bought new UPS for your server. How do you install it without
> bringing machine down? Suspend to disk, rearrange power cables,
> resume.

Why taking the maschine offline at all?
If you can read german, have a look to 

  http://www.feyrer.de/Texts/Troja/usv.html

-- 
TNG Technology Consulting GmbH   Andreas Lohrum, Partner
Mobil:   +49 179 537 2076        Andreas.Lohrum-r9+Sx7D/HENBDgjK7y7TUQ@public.gmane.org
Telefon: +49 89 2158 9960        http://www.tngtech.com
Fax:     +49 89 2158 9969           




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Runlevel for Sleep?

[P. Christeas]

Pavel Machek wrote:
> Hi!
>
> > connections. What happens if you are suspending a db server (well,
> > suspending a server is IMHO a really stupid thing, but...) and after
>
> Why?
>
Those are useful questions to ask. Scripts are flexible enough to handle 
special cases, we however have to ensure there are no stiff restrictions to 
those.

> You bought new UPS for your server. How do you install it without
> bringing machine down? Suspend to disk, rearrange power cables,
> resume.
>
> You have your server on UPS. Power died, and UPS is indicating 30
> seconds to failure. What do you do? Suspend to disk.
>
AFAIK there is already a 'low battery' line in 'inittab'. Following from that 
point, we should use that line (for ACPI) instead of directly (from a binary) 
trying to enter S4 or whatever. This way the root will chose how to handle 
such a situation. In some machines S4 may be broken (not ACPI's fault always, 
consider a mis-configured partition), there 'init 0' is the only safe way to 
go down (see S5). Only the root of the machine may know that.
This will certainly be a consideration point if we decide to implement (as a 
de-facto standard) the runlevel.

> Ethernet card in your server died. You want to replace it. Your
> server is not hotplug capable. What do you do? Suspend to disk,
> replace ethernet card, resume. If you are fast your users will not
> even see broken connections.
>
Q. Will that really work?  Won't the change of Ethernet MAC ruin that?
Anyway, everybody should be free to try that.

> [I've created FAQ section in Documentation/swsusp.txt; I'll put this
> question/answer in there in next merge.]
> 								Pavel



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Runlevel for Sleep?

[Pavel Machek]

Hi!

> > You bought new UPS for your server. How do you install it without
> > bringing machine down? Suspend to disk, rearrange power cables,
> > resume.
> >
> > You have your server on UPS. Power died, and UPS is indicating 30
> > seconds to failure. What do you do? Suspend to disk.
> >
> AFAIK there is already a 'low battery' line in 'inittab'. Following from that 
> point, we should use that line (for ACPI) instead of directly (from a binary) 
> trying to enter S4 or whatever. This way the root will chose how to handle 
> such a situation. In some machines S4 may be broken (not ACPI's fault always, 
> consider a mis-configured partition), there 'init 0' is the only safe way to 
> go down (see S5). Only the root of the machine may know that.
> This will certainly be a consideration point if we decide to implement (as a 
> de-facto standard) the runlevel.

Agreed, having it de-facto standard is very important. And inittab
looks like best solution.

> > Ethernet card in your server died. You want to replace it. Your
> > server is not hotplug capable. What do you do? Suspend to disk,
> > replace ethernet card, resume. If you are fast your users will not
> > even see broken connections.
> >
> Q. Will that really work?  Won't the change of Ethernet MAC ruin that?
> Anyway, everybody should be free to try that.

I was thinking ethernet card of some rarely used interface. Anyway MAC
is settable by software and even if you forget that ARPs should save
you.
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Runlevel for Sleep?

[Pavel Machek]

Hi!

> One more thing  (as Lyle Seaman has pointed out) is that sometimes we don't 
> want to suspend, even though the user has pressed the 'suspend
> button'. This 

Imagine notebook running out of batteries. You don't want to
completely drain batteries then crash because userspace is 100MB in
swap and can not react in time.
								Pavel 
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Runlevel for Sleep?

[Lyle Seaman]

> umounting nfs seems like good idea, and no ammount of drivers will fix that.

Can't unmount it if there are open files.  I don't agree that unmounting NFS is necessarily a good idea -- I want everything to resume exactly the way it was suspended to the greatest extent possible.  If the server has gone away and returned, well, that can't be helped. But otherwise, I would expect all my network resources to be in the same state as I left them, just as with my local resources.





-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

swsusp and ac status

[Daniele Boffi]

Hi,
I noticed that a change in the ac status is not detected after a swsusp. I
think this should be a known issue; is there any workaround available?

How to reproduce the bad behavior:

- swsuspend when on ac (resp. battery) power
- unplug (resp. plug) the ac adapter when the laptop is off
- resume when on battery (resp. ac) power

Then /proc/acpi/ac_adapter/*/state says "on-line" (resp. "off-line").
A new change in the status is then correctly detected.

I tried different acpi configurations (ac in the kernel or as a module, unload
the ac module before suspending and reload it after resuming...) with no
success.

actual kernel 2.6.7 (same behavior with previous ones), no acpi patch, swsusp2
patch

Same behavior with pm-suspend, swsusp and swsusp2.

Daniele


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: swsusp and ac status

[Stefan Seyfried]

On Wed, Jun 23, 2004 at 08:26:53AM +0200, Daniele Boffi wrote:
> Hi,
> I noticed that a change in the ac status is not detected after a swsusp. I
> think this should be a known issue; is there any workaround available?

What machine? hp compaq nx5000?
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: swsusp and ac status

[Pavel Machek]

Hi!

> I noticed that a change in the ac status is not detected after a swsusp. I
> think this should be a known issue; is there any workaround available?

Its known, and yes I have ugly workaround.

> Same behavior with pm-suspend, swsusp and swsusp2.

Can you try pm-suspend with powerdown mode set to "platform"?
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

[PATCH] Toshiba ACPI Extras 0.16

[John Belmonte]

[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]

Hello Andy,

Recently there was a mass patch to the 2.5 kernel that tried to replace 
instances of strncpy with strlcpy.  In the case of my driver the 
substitution was not appropriate and causes end-user problems due to the 
resulting undefined memory access.  This change was made about 6 weeks 
ago without my knowledge, the result being that there are tainted copies 
of version 0.15 of the driver out there.

What I'd like to do is forget version 0.15 ever existed, so this patch 
reverts the change and increments the version.  I'd also like to 
increment the version in the 2.4 tree to keep things in sync, so I've 
got a patch ready for each tree.

Unfortunately I've complicated matters by already trying to submit a 
patch to Linus that reverts the change but doesn't increment the 
version.  I doubt he'll apply it, but if he does before you get to it 
then apply the 2.4 patch to the 2.5 tree to increment the version only.

Sorry for the trouble.

Regards,
-John


Changes:

     * Increment version because release 0.15 was tainted by a bad
       "strlcpy conversion" patch.




[-- Attachment #2: toshiba_acpi_0.16-linux_2.6.0-test1.patch --]
[-- Type: text/plain, Size: 598 bytes --]

--- toshiba_acpi.c.old	2003-07-25 18:40:52.000000000 -0400
+++ toshiba_acpi.c	2003-07-25 18:24:48.000000000 -0400
@@ -33,7 +33,7 @@
  *
  */
 
-#define TOSHIBA_ACPI_VERSION	"0.15"
+#define TOSHIBA_ACPI_VERSION	"0.16"
 #define PROC_INTERFACE_VERSION	1
 
 #include <linux/kernel.h>
@@ -108,7 +108,9 @@
 	int result;
 	char* str2 = kmalloc(n + 1, GFP_KERNEL);
 	if (str2 == 0) return 0;
-	strlcpy(str2, str, n);
+	/* NOTE: don't even _think_ about replacing this with strlcpy */
+	strncpy(str2, str, n);
+	str2[n] = 0;
 	va_start(args, format);
 	result = vsscanf(str2, format, args);
 	va_end(args);

[-- Attachment #3: toshiba_acpi_0.16-linux_2.4.22-pre8.patch --]
[-- Type: text/plain, Size: 517 bytes --]

--- toshiba_acpi.c.old	2003-07-25 19:03:10.000000000 -0400
+++ toshiba_acpi.c	2003-07-25 18:24:48.000000000 -0400
@@ -33,7 +33,7 @@
  *
  */
 
-#define TOSHIBA_ACPI_VERSION	"0.15"
+#define TOSHIBA_ACPI_VERSION	"0.16"
 #define PROC_INTERFACE_VERSION	1
 
 #include <linux/kernel.h>
@@ -108,6 +108,7 @@
 	int result;
 	char* str2 = kmalloc(n + 1, GFP_KERNEL);
 	if (str2 == 0) return 0;
+	/* NOTE: don't even _think_ about replacing this with strlcpy */
 	strncpy(str2, str, n);
 	str2[n] = 0;
 	va_start(args, format);

Re: [PATCH] Toshiba ACPI Extras 0.16

[Matthew Wilcox]

On Fri, Jul 25, 2003 at 07:28:17PM -0400, John Belmonte wrote:
> @@ -108,7 +108,9 @@
>  	int result;
>  	char* str2 = kmalloc(n + 1, GFP_KERNEL);
>  	if (str2 == 0) return 0;
> -	strlcpy(str2, str, n);
> +	/* NOTE: don't even _think_ about replacing this with strlcpy */
> +	strncpy(str2, str, n);
> +	str2[n] = 0;
>  	va_start(args, format);
>  	result = vsscanf(str2, format, args);
>  	va_end(args);

seems to me you'd be better off doing ...

	len = strlen(str);
	if (len > n)
		len = n;
	memcpy(str2, str, n);
	str2[n] = '\0';

i wrote a short note entitled "strncpy Considered Harmful" a few years ago.
unfortunately, it seems lost in time.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

[parisc-linux] cvs [login aborted]?

[Joel Soete]

Hi pa,

Is it an actual cvs server pb or a local pb I could have:
those last two days cvs -d :pserver:anonymous@cvs.parisc-linux.org:/var/cvs
"failed: Connection timed out"?

Any idea?

Thanks,
    Joel


------------------------------------------------------
Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003.
On s'habitue vite à payer son ADSL moins cher!
Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr 

Re: [parisc-linux] cvs [login aborted]?

[Matthew Wilcox]

On Fri, Jul 18, 2003 at 07:27:43AM +0200, Joel Soete wrote:
> Hi pa,
> 
> Is it an actual cvs server pb or a local pb I could have:
> those last two days cvs -d :pserver:anonymous@cvs.parisc-linux.org:/var/cvs
> "failed: Connection timed out"?

Hm, it's not working for me either:

willy@honeydew:~/kernel/pci-2.5$ cvs up Makefile 
cvs [update aborted]: connect to cvs.parisc-linux.org(192.25.206.14):2401 failed: Connection timed out
willy@honeydew:~/kernel/pci-2.5$ cat CVS/Root 
:pserver:anonymous@cvs.parisc-linux.org:/var/cvs

I think someone must have changed the firewall config because I can
reach port 2401 from localhost, but not from any other machine.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] cvs [login aborted]?

[bame]

> I think someone must have changed the firewall config because I can
> reach port 2401 from localhost, but not from any other machine.

I don't know how that happened, but I reopened the port and anon
CVS should work now.

	-P

Re: 2.5.34?

[Brad Parker]

Pavel Machek wrote:
>
>No. S3 wakeup is completely different from S4 wakeup.

Really?  I thought they both used the same "wakeup vector" and hence
used the pre-_WAK code path.  Perhaps I am mistaken.

>And bothworked for me in 2.5.32 IIRC.

ok, thanks.  That's actually the first time anyone has said that clearly.

(your previous email was somewhat vague about S3 working - it didn't
actually state that it was working and when)

>Look at acpi_wakeup.S. If your mode is in  text VGA you can just write
>to videoram. Maybe code to do that is still there?

The problem is that the backlight is not on, and it's not clear the
vga controller is turned on.  This code runs before _WAK (which I think
is what turns on the backlight)

I'll try it, however, as it's a reasonable suggestion.  thanks!

-brad


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: 2.5.34?

[Pavel Machek]

Hi!

> >No. S3 wakeup is completely different from S4 wakeup.
> 
> Really?  I thought they both used the same "wakeup vector" and hence
> used the pre-_WAK code path.  Perhaps I am mistaken.

Well, we do S3 using ACPI but do S4 "by hand", so wakeup vector is not
even used in S4 (==swsusp) case.

S3 is similar to S4bios; there are patches for S4bios floating around,
but its not in mainline.

> >And bothworked for me in 2.5.32 IIRC.
> 
> ok, thanks.  That's actually the first time anyone has said that clearly.
> 
> (your previous email was somewhat vague about S3 working - it didn't
> actually state that it was working and when)

[I'm not 100% sure about it was 2.5.32. I think it was.]

> >Look at acpi_wakeup.S. If your mode is in  text VGA you can just write
> >to videoram. Maybe code to do that is still there?
> 
> The problem is that the backlight is not on, and it's not clear the
> vga controller is turned on.  This code runs before _WAK (which I think
> is what turns on the backlight)
> 
> I'll try it, however, as it's a reasonable suggestion.  thanks!

On my machines I'm lucky enough to have video either in VGA text or in
original mode. In VGA text it is rather easy to show some debugging.

								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: swsusp and ac status

[Daniele Boffi]

> > I noticed that a change in the ac status is not detected after a swsusp. I
> > think this should be a known issue; is there any workaround available?
> 
> Its known, and yes I have ugly workaround.
> 
> > Same behavior with pm-suspend, swsusp and swsusp2.
> 
> Can you try pm-suspend with powerdown mode set to "platform"?

I did and it WORKS!
In my kernel configuration I have all acpi compiled in the kernel (no 
modules).
This probably means there is something wrong with how swsusp2 handles
acpi.

Daniele




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: swsusp and ac status

[Pavel Machek]

Hi!

> > > I noticed that a change in the ac status is not detected after a swsusp. I
> > > think this should be a known issue; is there any workaround available?
> > 
> > Its known, and yes I have ugly workaround.
> > 
> > > Same behavior with pm-suspend, swsusp and swsusp2.
> > 
> > Can you try pm-suspend with powerdown mode set to "platform"?
> 
> I did and it WORKS!
> In my kernel configuration I have all acpi compiled in the kernel (no 
> modules).
> This probably means there is something wrong with how swsusp2 handles
> acpi.

There's nothing wrong, just missing code to do S4 properly. pm-disk is
only one that can do it right at this point.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

2.5.34?

[Gustavo Sverzut Barbieri]

Hello,

Is 2.5.34 patch comming out soon?


Gustavo

_______________________________________________________________________
Yahoo! PageBuilder
O super editor para criação de sites: é grátis, fácil e rápido.
http://br.geocities.yahoo.com/v/pb.html


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: 2.5.34?

[Matthew Wilcox]

On Sun, Sep 15, 2002 at 09:14:25PM -0300, Gustavo Sverzut Barbieri wrote:
> Hello,
> 
> Is 2.5.34 patch comming out soon?

i don't particularly see the point in releasing one since all ACPI patches
for 2.5 that i'm aware of are integrated into the current bitkeeper tree.
you could grab a nightly snapshot if you can't wait for 2.5.35:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/patch-2.5.34-bk6.bz2

-- 
Revolutions do not require corporate support.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: 2.5.34?

[Toon van der Pas]

On Mon, Sep 16, 2002 at 01:25:06AM +0100, Matthew Wilcox wrote:
> On Sun, Sep 15, 2002 at 09:14:25PM -0300, Gustavo Sverzut Barbieri wrote:
> > Hello,
> > 
> > Is 2.5.34 patch comming out soon?
> 
> i don't particularly see the point in releasing one since all ACPI patches
> for 2.5 that i'm aware of are integrated into the current bitkeeper tree.
> you could grab a nightly snapshot if you can't wait for 2.5.35:
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/patch-2.5.34-bk6.bz2

But be aware that the swsusp patch in the IDE driver in de 2.5 kernel
was lost when Martin Dalecki's IDE project was removed!
I would wait for it to return in some form or another, if I where you.

Regards,
Toon.
-- 
 /"\                             |
 \ /     ASCII RIBBON CAMPAIGN   |  "Who is this General Failure, and
  X        AGAINST HTML MAIL     |   what is he doing on my harddisk?"
 / \


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: 2.5.34?

[Pavel Machek]

Hi

> > > Is 2.5.34 patch comming out soon?
> > 
> > i don't particularly see the point in releasing one since all ACPI patches
> > for 2.5 that i'm aware of are integrated into the current bitkeeper tree.
> > you could grab a nightly snapshot if you can't wait for 2.5.35:
> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/patch-2.5.34-bk6.bz2
> 
> But be aware that the swsusp patch in the IDE driver in de 2.5 kernel
> was lost when Martin Dalecki's IDE project was removed!
> I would wait for it to return in some form or another, if I where you.

Look at l-k, I already submitted IDE swsusp support to Andre.

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: 2.5.34?

[Toon van der Pas]

On Tue, Sep 17, 2002 at 03:46:53PM +0000, Pavel Machek wrote:
> 
> > > > Is 2.5.34 patch comming out soon?
> > > 
> > > i don't particularly see the point in releasing one since all ACPI patches
> > > for 2.5 that i'm aware of are integrated into the current bitkeeper tree.
> > > you could grab a nightly snapshot if you can't wait for 2.5.35:
> > > http://www.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/patch-2.5.34-bk6.bz2
> > 
> > But be aware that the swsusp patch in the IDE driver in de 2.5 kernel
> > was lost when Martin Dalecki's IDE project was removed!
> > I would wait for it to return in some form or another, if I where you.
> 
> Look at l-k, I already submitted IDE swsusp support to Andre.

I know.
I got my information from your postings on the linux-kernel mailing list. 
My only intention was to warn people that their data is NOT safe when
using swsusp with recent 2.5 kernels.

I should have added that you already submitted a patch on the
linux-kernel mailing list. Sorry about that.

BTW: From your discussion with André Hedrick I understood that there
still is some disagreement about the layer where the I/O to the IDE
block devices should be blocked by swsusp. Is this resolved now?

Regards,
Toon.
-- 
 /"\                             |
 \ /     ASCII RIBBON CAMPAIGN   |  "Who is this General Failure, and
  X        AGAINST HTML MAIL     |   what is he doing on my harddisk?"
 / \


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: 2.5.34?

[Pavel Machek]

Hi!

> > Look at l-k, I already submitted IDE swsusp support to Andre.
> 
> I know.
> I got my information from your postings on the linux-kernel mailing list. 
> My only intention was to warn people that their data is NOT safe when
> using swsusp with recent 2.5 kernels.
> 
> I should have added that you already submitted a patch on the
> linux-kernel mailing list. Sorry about that.
> 
> BTW: From your discussion with André Hedrick I understood that there
> still is some disagreement about the layer where the I/O to the IDE
> block devices should be blocked by swsusp. Is this resolved now?

No but we are working on it.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: 2.5.34?

[Brad Parker]

Matthew Wilcox wrote:
...
>you could grab a nightly snapshot if you can't wait for 2.5.35:
>http://www.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/patch-2.5.34-bk
>6.bz2

Hi,

This link doesn't work; there's no .../jgarzik/snap directory.

Can anyone provide a coherent description of the S3 support in 2.5.34?
Is it close?  does it need patches (like the one above?)

I'm willing to put some work into it but I'd benefit from whom ever is
closest to it giving a quick status.

It seems like if S4 can be made to work, S3 should be straightforward
(heh).  If tried it in a stock 2.5.34 and found no difference from the
2.2.x acpi patched kernels I use...

-brad





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: 2.5.34?

[Matthew Wilcox]

On Mon, Sep 16, 2002 at 07:30:50AM -0400, Brad Parker wrote:
> 
> Matthew Wilcox wrote:
> ...
> >you could grab a nightly snapshot if you can't wait for 2.5.35:
> >http://www.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/patch-2.5.34-bk
> >6.bz2
> 
> Hi,
> 
> This link doesn't work; there's no .../jgarzik/snap directory.

looks like jeff moved it:
http://www.kernel.org/pub/linux/kernel/v2.5/snapshots/

but 2.5.35 is out, so there's no need any more ;-)

-- 
Revolutions do not require corporate support.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: 2.5.34?

[Pavel Machek]

Hi!

> Can anyone provide a coherent description of the S3 support in 2.5.34?
> Is it close?  does it need patches (like the one above?)

It worked before. IDE support is recommended, through.

> I'm willing to put some work into it but I'd benefit from whom ever is
> closest to it giving a quick status.
> 
> It seems like if S4 can be made to work, S3 should be straightforward
> (heh).  If tried it in a stock 2.5.34 and found no difference from the
> 2.2.x acpi patched kernels I use...

S3 is not as simple as you think, but as it worked before... It should
be easy.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

RE: Runlevel for Sleep?

[Grover, Andrew]

> From: P. Christeas [mailto:p_christ-U04EIuiosng@public.gmane.org] 
> It has just come up to me, should we use a runlevel for sleep?

Right now I am leaning towards no. We don't have a runlevel for APM's
suspend, why would we for ACPI sleep?

Sleep should be very quick to enter and exit. We shouldn't have to shut down
any services. If the drivers properly save and restore context, things on
resume should just pick up where they left off.

I think we'll know better once we have working device power management if a
new runlevel is needed or not.

Regards -- Andy


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

[parisc-linux] HP9000/L2000 + FC60 Fiber Support

[António Ribeiro]

Hi,

Can anyone let me know is this cards are supported and they can be attached
to the FC60 from HP.


  Bus 16, device   0, function  0:
    Fibre Channel: PCI device 103c:1028 (Hewlett-Packard Company) (rev 11).
      IRQ 256.
      Master Capable.  No bursts.  Min Gnt=32.
      I/O at 0x20000 [0x200ff].
      I/O at 0x20100 [0x201ff].
      Non-prefetchable 32 bit memory at 0xfffffffff9040000
[0xfffffffff90401ff].
      Non-prefetchable 32 bit memory at 0xfffffffff9000000
[0xfffffffff901ffff].
  Bus 24, device   0, function  0:
    Fibre Channel: PCI device 103c:1028 (Hewlett-Packard Company) (rev 11).
      IRQ 320.
      Master Capable.  No bursts.  Min Gnt=32.
      I/O at 0x30000 [0x300ff].
      I/O at 0x30100 [0x301ff].
      Non-prefetchable 32 bit memory at 0xfffffffff9840000
[0xfffffffff98401ff].
      Non-prefetchable 32 bit memory at 0xfffffffff9800000
[0xfffffffff981ffff].


Thanks.

Antonio

Re: [parisc-linux] HP9000/L2000 + FC60 Fiber Support

[Matthew Wilcox]

On Tue, Aug 13, 2002 at 02:23:49PM +0100, António Ribeiro wrote:
>     Fibre Channel: PCI device 103c:1028 (Hewlett-Packard Company) (rev 11).

according to the latest pci.ids, this is:
Tach TL Fibre Channel Host Adapter

hope this helps someone determine whether or not it's supported.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] HP9000/L2000 + FC60 Fiber Support

[Grant Grundler]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 338 bytes --]

Matthew Wilcox wrote:
> On Tue, Aug 13, 2002 at 02:23:49PM +0100, António Ribeiro wrote:
> >     Fibre Channel: PCI device 103c:1028 (Hewlett-Packard Company) (rev 11).
> 
> according to the latest pci.ids, this is:
> Tach TL Fibre Channel Host Adapter

http://lists.parisc-linux.org/pipermail/parisc-linux/2002-August/017288.html

grant

[parisc-linux] O_DIRECT on devices

[Patrick Caulfield]

I'm currently working on LVM2 and we want to use O_DIRECT to write the metadata
from userspace. so I open a partition with O_DIRECT and try to read/write the
data from an aligned buffer.

This works fine on Alpha & Intel but seems very unreliable on parisc for some
reason. Sometimes it works, sometimes it oopses "do_page_fault() pid=2120
command='lvm' type=15 address=0x00000001" and sometimes I just get back the
wrong information (at least LVM thinks its wrong I haven't check in detail just
what is up with it).

I haven't tried writing yet - I'd rather not think what might happen to my disk
just ATM :)

This is a C110 with 256meg of memory running 2.4.18-pa46

patrick

Re: [parisc-linux] O_DIRECT on devices

[Patrick Caulfield]

On Thu, Jul 11, 2002 at 11:09:31AM +0200, Rodolfo Baselli wrote:
> Patrick Caulfield wrote:
> >I'm currently working on LVM2 and we want to use O_DIRECT to write the 
> >metadata
> >from userspace. so I open a partition with O_DIRECT and try to read/write 
> >the
> >data from an aligned buffer.
> 
> Hmmm, so is LVM ready for HP PA-RISC Linux? WOW!

LVM2 works fine - I use it all the time on my HP and Alpha boxes. O_DIRECT is an
optimisation I would like to have in there though cos it avoids a lot of
buffer-cache nastiness when clustering (yes, I'm working on that too but that
bit won't be GPLed)

 
> By the way, I'm reading right now "The catcher in the rye" by J.D. 
> Salinger, and as I glanced at your 2nd name I felt like I was still 
> reading the book! :-)))

:-)


If you were a pop-art expert you might have got even more deja-vu !
http://www.postershop.com/Caulfield-Patrick/Caulfield-Patrick-After-Lunch-2405657.html

I blame my parents...

patrick

Re: [parisc-linux] O_DIRECT on devices

[Matthew Wilcox]

On Thu, Jul 11, 2002 at 09:22:59AM +0100, Patrick Caulfield wrote:
> This works fine on Alpha & Intel but seems very unreliable on parisc for some
> reason. Sometimes it works, sometimes it oopses "do_page_fault() pid=2120
> command='lvm' type=15 address=0x00000001" and sometimes I just get back the
> wrong information (at least LVM thinks its wrong I haven't check in detail just
> what is up with it).

pid 2120 did a NULL pointer dereference ... you should be able to trace
it with the IAOQ, perhaps.  I'm not sure whether anyone's really played
with the O_DIRECT code yet, it could well be buggy on PA.  What you're
seeing sounds like bogus cache behaviour.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] O_DIRECT on devices

[Grant Grundler]

Matthew Wilcox wrote:
> What you're seeing sounds like bogus cache behaviour.

Randolph and I think most SMP bugs reported (and we seen ourselves)
suggest a D-cache problem.

My theory is virtual addresses are flushed on one CPU but any data 
accessed through an aliases on another CPU are not flushed. And then
we end up with an inconsistency.

We've been reading Documentation/cachetlb.txt and trying
to understand what it says about virtually indexed caches.

The other thing is we don't hit the problems with PA8500 - only PA8700.
I'm guessing the aliasing or timing is quite different betweem the two.
Maybe someone else knows more?

grant

Re: [parisc-linux] O_DIRECT on devices

[Matthew Wilcox]

On Mon, Jul 15, 2002 at 01:42:19AM -0600, Grant Grundler wrote:
> Randolph and I think most SMP bugs reported (and we seen ourselves)
> suggest a D-cache problem.

Entirely plausible.  PA has bigger virtually indexed caches than anyone
else, so we're more susceptible to cache aliasing bugs than anyone else.
It could be a missing flush somewhere in the arch-independent code.

> My theory is virtual addresses are flushed on one CPU but any data 
> accessed through an aliases on another CPU are not flushed. And then
> we end up with an inconsistency.

it's certainly possible... i don't claim to understand exactly how this
works, but my recollection is that some of the flush instructions are
cpu-local whereas others are global to the system.  you'd have to ask
jsm about it, really.

> We've been reading Documentation/cachetlb.txt and trying
> to understand what it says about virtually indexed caches.

It seems pretty straightforward to me... am I missing something?

> The other thing is we don't hit the problems with PA8500 - only PA8700.
> I'm guessing the aliasing or timing is quite different betweem the two.
> Maybe someone else knows more?

8700 has bigger caches than 8500 and more TLB entries, so it may be
easier to hit problems.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] O_DIRECT on devices

[Patrick Caulfield]

On Mon, Jul 15, 2002 at 12:29:19PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 15, 2002 at 01:42:19AM -0600, Grant Grundler wrote:
> > Randolph and I think most SMP bugs reported (and we seen ourselves)
> > suggest a D-cache problem.
> 
> Entirely plausible.  PA has bigger virtually indexed caches than anyone
> else, so we're more susceptible to cache aliasing bugs than anyone else.
> It could be a missing flush somewhere in the arch-independent code.

My machine isn't SMP but could a similar bug cause the problem to occur between
the CPU and the DMA controller of the SCSI card ?

patrick

Re: [parisc-linux] O_DIRECT on devices

[Matthew Wilcox]

On Mon, Jul 15, 2002 at 02:57:57PM +0100, Patrick Caulfield wrote:
> My machine isn't SMP but could a similar bug cause the problem to occur between
> the CPU and the DMA controller of the SCSI card ?

you're on a C110, right?  that has a ccio IOC so you shouldn't have any
problems, unless there's a driver bug.  and the symbios driver gets a
lot of testing ;-)

what we could be seeing on your machine is incoherency between user &
kernel space.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] O_DIRECT on devices

[Patrick Caulfield]

On Mon, Jul 15, 2002 at 03:10:13PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 15, 2002 at 02:57:57PM +0100, Patrick Caulfield wrote:
> > My machine isn't SMP but could a similar bug cause the problem to occur between
> > the CPU and the DMA controller of the SCSI card ?
> 
> you're on a C110, right?  that has a ccio IOC so you shouldn't have any
> problems, unless there's a driver bug.  and the symbios driver gets a
> lot of testing ;-)

yes.
 
> what we could be seeing on your machine is incoherency between user &
> kernel space.

ah OK. makes sense.

patrick

Re: 2.5.34?

[Brad Parker]

Matthew Wilcox wrote:
>
>but 2.5.35 is out, so there's no need any more ;-)

ok, I'll try 2.5.35;  Is there a changelog for acpi? (other than the
kernel changelog)

S1 is working for me with 2.4.19, but even if I throttle back the cpu it
eats a lot of power (and generates a lot of heat!)

I've been fooling around with S3.  It looks like the big recent
additions (in 2.5) are to try and set the video mode in the wakeup
callback.  I keep sending email to the list but I have not heard from
anyone talk about the status of this code.

I want to ask "does the s3 wakeup code work for anyone?"; I suspect it
does since I've read reports that S4 is working for some and it uses
the same code path (for wakeup anyway).

Any suggestions how to debug this?  I would hack in some code to spit
messages out the uart but my hp laptop doesn't have one :-) I may try
a pcmcia 16550 card and a kgdb hack...

S3 puts it to sleep fine but when I wake up it seem to be hung - no lcd,
no keyboard...  It's pretty hard to say how far it gets.

-brad


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: 2.5.34?

[Pavel Machek]

Hi!

> >but 2.5.35 is out, so there's no need any more ;-)
> 
> ok, I'll try 2.5.35;  Is there a changelog for acpi? (other than the
> kernel changelog)
> 
> S1 is working for me with 2.4.19, but even if I throttle back the cpu it
> eats a lot of power (and generates a lot of heat!)
> 
> I've been fooling around with S3.  It looks like the big recent
> additions (in 2.5) are to try and set the video mode in the wakeup
> callback.  I keep sending email to the list but I have not heard from
> anyone talk about the status of this code.

In such case... you are not listening.

> I want to ask "does the s3 wakeup code work for anyone?"; I suspect it
> does since I've read reports that S4 is working for some and it uses
> the same code path (for wakeup anyway).

No. S3 wakeup is completely different from S4 wakeup.

And bothworked for me in 2.5.32 IIRC.

> Any suggestions how to debug this?  I would hack in some code to spit
> messages out the uart but my hp laptop doesn't have one :-) I may try
> a pcmcia 16550 card and a kgdb hack...
> 
> S3 puts it to sleep fine but when I wake up it seem to be hung - no lcd,
> no keyboard...  It's pretty hard to say how far it gets.

Look at acpi_wakeup.S. If your mode is in  text VGA you can just write
to videoram. Maybe code to do that is still there?
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: [PATCH] Toshiba ACPI Extras 0.16

[Lyle Seaman]

> seems to me you'd be better off doing ...
> 
> 	len = strlen(str);
> 	if (len > n)
> 		len = n;
> 	memcpy(str2, str, n);
> 	str2[n] = '\0';
> 
> i wrote a short note entitled "strncpy Considered Harmful" a few years ago.
> unfortunately, it seems lost in time.

Obviously, you meant: 	memcpy(str2, str, len);

But strlen() is dangerous when you point it at something that you can't swear is null-terminated.  It almost always works because, somewhere along the line, there's a null byte.  BUT, it *is* walking off the end of your string and poking about in memory, and you never know what that might do.

You could just do this:
	memcpy(str2, str, n); 	str2[n] = '\0';

But, enlighten me.  What's wrong with strncpy, that is solved by doing the above?




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: [PATCH] Toshiba ACPI Extras 0.16

[M. Warner Losh]

So what was wrong with strlcpy?  Was strncpy used because trailing
NULs for the length of the field was required?  That, and the point
below, are the only differences between two versions of the code
posted.

Also:
	strncyp(str2, str, n); str2[n] = '\0';
means that you copy n + 1 bytes into str2, which is typically a bug,
so a comment explaining why it isn't would be in order.

As it is the comment of 'don't even consider using strlcpy' is about
useless because it tells what, but not why.  And there's a long
history of people in the Linux world ignoring dictates when the
reasons get lost in the mists of time.

Warner


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: [PATCH] Toshiba ACPI Extras 0.16

[John Belmonte]

M. Warner Losh wrote:
> So what was wrong with strlcpy?  Was strncpy used because trailing
> NULs for the length of the field was required?  That, and the point
> below, are the only differences between two versions of the code
> posted.

The strlcpy function expects the input string to be zero-terminated, 
which is not the case here.

> Also:
> 	strncyp(str2, str, n); str2[n] = '\0';
> means that you copy n + 1 bytes into str2, which is typically a bug,
> so a comment explaining why it isn't would be in order.

It isn't a bug because

     char* str2 = kmalloc(n + 1, GFP_KERNEL)

> As it is the comment of 'don't even consider using strlcpy' is about
> useless because it tells what, but not why.  And there's a long
> history of people in the Linux world ignoring dictates when the
> reasons get lost in the mists of time.

What's going on is that someone made a conversion to my driver which was 
not functionally equivalent and caused a serious bug, and did not notify 
me of the change.  It's my name in the maintainer field and I have to 
deal with resulting bug reports.  I wasted an entire day tracking down 
exactly what happened, discussing it with the people involved and even 
more with those not involved, and preparing a correction.

This should have never happened, and the comment I added is only a 
reaction to this.  To me it states the obvious, "don't break my code", 
and indeed left to my own devices it wouldn't be there.


-- 
http:// if   l .o  /



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: [PATCH] Toshiba ACPI Extras 0.16

[John Belmonte]

Lyle Seaman wrote:
> But strlen() is dangerous when you point it at something that you
> can't swear is null-terminated.  It almost always works because,
> somewhere along the line, there's a null byte.  BUT, it *is* walking
> off the end of your string and poking about in memory, and you never
> know what that might do.

It's never acceptable to read undefined memory, and in this case it 
triggers real symptoms such as causing the driver or unrelated drivers 
to fail.



-- 
http:// if   l .o  /



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: [PATCH] Toshiba ACPI Extras 0.16

[John Belmonte]

Matthew Wilcox wrote:
> seems to me you'd be better off doing ...
> 
> 	len = strlen(str);
> 	if (len > n)
> 		len = n;
> 	memcpy(str2, str, n);
> 	str2[n] = '\0';
> 
> i wrote a short note entitled "strncpy Considered Harmful" a few years ago.
> unfortunately, it seems lost in time.

Since you have that experience then I would expect you to consider 
whether str is zero-terminated before suggesting that I change my code.



-- 
http:// if   l .o  /



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: [PATCH] Toshiba ACPI Extras 0.16

[Matthew Wilcox]

On Sat, Jul 26, 2003 at 05:25:04PM -0400, John Belmonte wrote:
> Matthew Wilcox wrote:
> >seems to me you'd be better off doing ...
> >
> >	len = strlen(str);
> >	if (len > n)
> >		len = n;
> >	memcpy(str2, str, n);
> >	str2[n] = '\0';
> >
> >i wrote a short note entitled "strncpy Considered Harmful" a few years ago.
> >unfortunately, it seems lost in time.
> 
> Since you have that experience then I would expect you to consider 
> whether str is zero-terminated before suggesting that I change my code.

ok, you want strnlen there then.  my original note was in the context of
how completely useless strncpy was for C strings.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Adam J. Richter]

>> = ???
>  = Patrick Mochel
>> I think the qualification for appearing in driverfs is actually possessing a 
>> driver.  Therefore, we accept FC and iSCSI.  Things which appear as 
>> FileSystems are debatable, but not anything which has a real device driver.
>
>The qualification for appearing in the device tree is the physical 
>presence of the device, regardless of the presence of a driver to control 
>it. (This typically depends on the presence of the bus driver so it can 
>discover the device.) Presence in the device tree implies presence in 
>driverfs.

	Lots of "soft" drivers, from /dev/lop to FC and iSCSI could
be simplified by using the struct device <--> struct device_driver
rendezvous code.  Under Patrick's propoposed, policy, we would not be
able to get the simplifications in scsi.c, usb.c, or anything else that
could possibly drive a device that was too "soft" for Patrick.

	It is also important for supporting hot plugging that user level
facilities understand that if ide disk #7 was removed that that
poisons /dev/loop/7.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Grover, Andrew]

> From: Roman Zippel [mailto:zippel@linux-m68k.org] 
> On Mon, 24 Jun 2002, Grover, Andrew wrote:
> > If a device can be accessed by multiple machines 
> concurrently, it should not
> > be in driverfs.
> 
> I don't think it's that easy. If the computer wakes up again, 
> devices have
> to be reinitialised in the right order, e.g. iSCSI needs a 
> working network
> stack and devices.

Would the iSCSI device be a child of the network device? That would ensure
that the NIC was fully restarted before the iSCSI device.

> Another problem is how to properly shutdown the
> machine. Scripts now "know" that nfs requires the network, 
> but how does
> the script find out, that /dev/sdb2 is an iSCSI device, so that it can
> properly unmount the device, before the network is shutdown?

Would a bottom-up traversal of the device tree do things properly?

Regards -- Andy

RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Oliver Xymoron]

On Mon, 24 Jun 2002, Grover, Andrew wrote:

> > From: Roman Zippel [mailto:zippel@linux-m68k.org]
> > On Mon, 24 Jun 2002, Grover, Andrew wrote:
> > > If a device can be accessed by multiple machines
> > concurrently, it should not
> > > be in driverfs.
> >
> > I don't think it's that easy. If the computer wakes up again,
> > devices have
> > to be reinitialised in the right order, e.g. iSCSI needs a
> > working network
> > stack and devices.
>
> Would the iSCSI device be a child of the network device? That would ensure
> that the NIC was fully restarted before the iSCSI device.

If by network device you mean NIC, the answer is no. Think redundant
routing. This problem already exists in the SCSI realm (multipathed
arrays) and there's I remember reading there's some multipath stuff in
place, but I doubt driverfs has really thought about it.

The multipath problem means our tree is really a DAG. Which may or may not
be a problem.

> > Another problem is how to properly shutdown the
> > machine. Scripts now "know" that nfs requires the network,
> > but how does
> > the script find out, that /dev/sdb2 is an iSCSI device, so that it can
> > properly unmount the device, before the network is shutdown?
>
> Would a bottom-up traversal of the device tree do things properly?

If we think in terms of DAGs instead of trees, yes.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Oliver Xymoron]

On Mon, 24 Jun 2002, Grover, Andrew wrote:

> > From: Roman Zippel [mailto:zippel@linux-m68k.org]
> > On Mon, 24 Jun 2002, Grover, Andrew wrote:
> > > If a device can be accessed by multiple machines
> > concurrently, it should not
> > > be in driverfs.
> >
> > I don't think it's that easy. If the computer wakes up again,
> > devices have
> > to be reinitialised in the right order, e.g. iSCSI needs a
> > working network
> > stack and devices.
>
> Would the iSCSI device be a child of the network device? That would ensure
> that the NIC was fully restarted before the iSCSI device.

If by network device you mean NIC, the answer is no. Think redundant
routing. This problem already exists in the SCSI realm (multipathed
arrays) and there's I remember reading there's some multipath stuff in
place, but I doubt driverfs has really thought about it.

The multipath problem means our tree is really a DAG. Which may or may not
be a problem.

> > Another problem is how to properly shutdown the
> > machine. Scripts now "know" that nfs requires the network,
> > but how does
> > the script find out, that /dev/sdb2 is an iSCSI device, so that it can
> > properly unmount the device, before the network is shutdown?
>
> Would a bottom-up traversal of the device tree do things properly?

If we think in terms of DAGs instead of trees, yes.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Grover, Andrew]

> From: James Bottomley [mailto:James.Bottomley@steeleye.com] 
> andrew.grover@intel.com said:
> > If a device can be accessed by multiple machines concurrently, it
> > should not be in driverfs. 
> 
> On that argument, we'll eliminate almost all Fibre Channel devices!
> 
> I think the qualification for appearing in driverfs is 
> actually possessing a 
> driver.  Therefore, we accept FC and iSCSI.  Things which appear as 
> FileSystems are debatable, but not anything which has a real 
> device driver.

OK that makes sense.

Regards -- Andy

RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Grover, Andrew]

> From: James Bottomley [mailto:James.Bottomley@steeleye.com] 
> andrew.grover@intel.com said:
> > If a device can be accessed by multiple machines concurrently, it
> > should not be in driverfs. 
> 
> On that argument, we'll eliminate almost all Fibre Channel devices!
> 
> I think the qualification for appearing in driverfs is 
> actually possessing a 
> driver.  Therefore, we accept FC and iSCSI.  Things which appear as 
> FileSystems are debatable, but not anything which has a real 
> device driver.

OK that makes sense.

Regards -- Andy

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map)

[Arnd Bergmann]

Grover, Andrew <Andrew.grover@intel.com> wrote on Sun Jun 23 2002:

> I know this is one of those things that has more and more cool
> possibilities the more you think about it but... 
>
> Is the device PHYSICALLY hooked up to the computer? If not, it shouldn't
> be in devicefs. 

So what do you do when none of the devices you are using is physically
attached :-) ?
On s390, we have an abstraction layer that allows us to use virtual 
devices without knowing the true hardware behind it. All we see is
an 'i/o subchannel' that typically equals a device (disk, tape, console
etc.).

I decided not to care about virtualization and have a device node in 
driverfs for each subchannel. Unfortunately, there are some devices (e.g. 
ethernet controllers) that are made up by multiple (two or three) 
subchannels, because some hardware engineers decided that it was a good 
idea to do that (for a good reason).

Now I have an extra bus type for those devices. They often do exist
physically (and I don't care if they are only virtual), so they need
a place in the device tree. Currently, each such device is a child node of 
one of the subchannels. This is not how it is meant to be in driverfs (there 
is no network device connected to a subchannel device, the network device
_is_ two subchannels), but what else should I do there?

Other drivers are purely virtual. The Inter-User Communication Vehicle
(iucv) lets me set up a network interface between two virtual machines.
I don't need a driverfs interface for it, but why shouldn't I have it 
anyway? It even fits the driver model better that my physical network
devices!

	Arnd <><

driverfs is not for everything! (was: [PATCH] /proc/scsi/map)

[Grover, Andrew]

> From: Nick Bellinger [mailto:nickb@attheoffice.org] 
> Giving the IP stack its own directory (leaf?) under driverfs 
> root sounds
> interesting enough and could have some potential uses, but in the case
> of iSCSI there are a few problems:

I know this is one of those things that has more and more cool possibilities
the more you think about it but...

Is the device PHYSICALLY hooked up to the computer? If not, it shouldn't be
in devicefs.

The device tree (for which devicefs is the fs representation) was originally
meant to enable good device power management and configuration. driverfs
wasn't meant to handle iscsi or tcpip (that is, network) connections, nor
should it have to.

Regards -- Andy

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map)

[David Brownell]

> Is the device PHYSICALLY hooked up to the computer? If not, it shouldn't be
> in devicefs.

What's "devicefs" -- some new filesystem?  Or a mis/re-naming of "driverfs"?
I assume you don't mean "devfs".


> The device tree (for which devicefs is the fs representation) was originally
> meant to enable good device power management and configuration. 

Surely a driver using IP-over-wire like iSCSI is no less deserving of appearing
in "driverfs" than one whose driver uses custom-protocol-over-a-"wire" like USB,
FireWire, FC, IR, SCSI, or Bluetooth?  I don't see why some disks (for example)
should deserve to be "more equal than others" -- and approved to be in driverfs.

Admittedly some of those may have few power management concerns beyond basic
startup/shutdown sequencing.  But the configuration management issues won't
go away just because a driver talks to a device over some more generalized
notion of wire.  I suspect those are probably more important, long-term, than
the power management hooks.  I seem to recall other operating systems starting
out with a device/driver tree well before power management existed, and was
surprised when I noticed Linux didn't have one yet.

No, of course driverfs isn't for everything.  But if it's not for all drivers,
then what's it for -- just power management?

- Dave

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map)

[Nick Bellinger]

On Sun, 2002-06-23 at 16:59, Grover, Andrew wrote:
> > From: Nick Bellinger [mailto:nickb@attheoffice.org] 
> > Giving the IP stack its own directory (leaf?) under driverfs 
> > root sounds
> > interesting enough and could have some potential uses, but in the case
> > of iSCSI there are a few problems:
> 
> I know this is one of those things that has more and more cool possibilities
> the more you think about it but...
> 
> Is the device PHYSICALLY hooked up to the computer? If not, it shouldn't be
> in devicefs.

This is a red herring,  what exactly is the definition of physically
hooked up to the computer?  In the above context it comes out as being a
device inside the machine or within close proximity (ie: USB, IEEE 1394,
etc) and connected by a physical cable.  If this is the case then what
becomes of an Fibre Channel array 10km removed?  What makes this more or
less likely to be in driverfs than a IP storage array that is
"physically connected" via gigabit ethernet cable in the next room?  If
you where getting at devices which use the IP stack exclusively, then
how do iSCSI HBAs with TCP offload engines fit into the mix?  The only
scenario where I see the above statement holding true is if one was to
use iSCSI over a wireless/radio link, then it most definitely could NOT
be part of driverfs. :)

But seriously, I was not implying that every TCP/UDP service should have
its own directory entry within driverfs or that the IP stack should be
included at all,  but rather looking from a wider perspective of how
logical devices not on the machine's bus which _should_ be part of
driverfs will fit into the framework.         

> 
> The device tree (for which devicefs is the fs representation) was originally
> meant to enable good device power management and configuration. driverfs
> wasn't meant to handle iscsi or tcpip (that is, network) connections, nor
> should it have to.

I am by no means fimilar with the original intent of driverfs,  but what
it appears to be morphing into (one of its uses of course) is a tree for
the user to view a list of all the devices within the system.  But again
the notion that only physically connected, and not by network cable
devices have a place in the tree simply does not make sense.  

I am all for keeping the tree as tidy as possible,  but any block level
storage transport regardless of physical (or non-physical :) connection
deserves a place in driverfs,  and will only become more apparent as
storage continues to work itself out onto the network.    

> 
> Regards -- Andy
> 

			Nicholas Bellinger

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map)

[Brad Hards]

On Mon, 24 Jun 2002 15:18, Nick Bellinger wrote:
> This is a red herring,  what exactly is the definition of physically
> hooked up to the computer?  In the above context it comes out as being a
> device inside the machine or within close proximity (ie: USB, IEEE 1394,
> etc) and connected by a physical cable.  If this is the case then what
> becomes of an Fibre Channel array 10km removed?  What makes this more or
> less likely to be in driverfs than a IP storage array that is
> "physically connected" via gigabit ethernet cable in the next room?  If
> you where getting at devices which use the IP stack exclusively, then
> how do iSCSI HBAs with TCP offload engines fit into the mix?  The only
> scenario where I see the above statement holding true is if one was to
> use iSCSI over a wireless/radio link, then it most definitely could NOT
> be part of driverfs. :)
I think if you are mounting the remote filesystem (or otherwise using it in 
some stateful way), then it appears in driverfs at mount time. This is 
because it becomes important at that point - you now have a dependency on the 
underlying transport (the PCI bus better not be shut down before I get the 
dirty pages out over the network card to the storage array).

Brad
-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map)

[Patrick Mochel]

> Is the device PHYSICALLY hooked up to the computer? If not, it shouldn't be
> in devicefs.

But, it should be in driverfs. I'll let the devicefs people decide what to 
do ;)

> The device tree (for which devicefs is the fs representation) was originally
> meant to enable good device power management and configuration. driverfs
> wasn't meant to handle iscsi or tcpip (that is, network) connections, nor
> should it have to.

Both statements are entirely true. driverfs doesn't care about device
types. The only thing the filesystem does is export the kernel data
structures and the relationships between them.

But, those devices are physical devices that the kernel is communicating 
with. Which is exactly what the device tree was designed to do.

	-pat

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map)

[Patrick Mochel]

> Is the device PHYSICALLY hooked up to the computer? If not, it shouldn't be
> in devicefs.

But, it should be in driverfs. I'll let the devicefs people decide what to 
do ;)

> The device tree (for which devicefs is the fs representation) was originally
> meant to enable good device power management and configuration. driverfs
> wasn't meant to handle iscsi or tcpip (that is, network) connections, nor
> should it have to.

Both statements are entirely true. driverfs doesn't care about device
types. The only thing the filesystem does is export the kernel data
structures and the relationships between them.

But, those devices are physical devices that the kernel is communicating 
with. Which is exactly what the device tree was designed to do.

	-pat