* Re: Re linux-hotplug-devel Re USBdesktop integration - how to guess /dev/sd* when
@ 2004-02-13 12:39 Michael Hamilton
2004-02-13 12:54 ` Re linux-hotplug-devel Re USBdesktop integration - how to guess Wout Mertens
2004-02-13 22:08 ` linux-hotplug-devel Re USBdesktop integration - how to guess /dev/sd* when Michael Hamilton
0 siblings, 2 replies; 3+ messages in thread
From: Michael Hamilton @ 2004-02-13 12:39 UTC (permalink / raw)
To: linux-hotplug
On Sat, 14 Feb 2004 00:11, Wout Mertens wrote:
> Interesting... Where do I assume 1 partition and fat? I just let mount
> figure it out. With Linux 2.4 I iterate through all partitions, and
> with 2.6, the block event takes care of that.
>
> Apart from that, any devfs-isms that might be there should be easily
> fixable. Why don't you just give it a shot? :)
>
> Wout.
>
> Tomorrow at 00:01, Michael Hamilton wrote:
>>...
I just lept to that assumption from the comments in the 2.4
version
# TODO use fdisk to figure out partitions and types
and also from the loading and unloading of the vfat module.
I should have read the script though more thouroughly.
Sorry about that.
But, I also can't see how
ls /dev/scsi/host$SCSI/
in the 2.4 version can be made to work on Redhat 9. But I guess
I could merge some code from my stuff to get the same effect.
Also under 2.6 my $DEVPATH contains more than the three parts
your scripts are looking for, eg /devices/pci0000:00/0000:00:11.2/usb3/3-2/3-2:1.0
So I was a bit mystified. Getting from the above to
/dev/sda /dev/sdb seems to be very difficult without using
something like sg_map. Perhaps I'm wrong to be sticking with
the old /dev/sd[abc...] stuff, and for sticking with Redhat
and its hotplug - but I was hoping that I could use 2.6 without
any major changes. I have pretty much achieved this goal -
except that I have to install another utility, sg_map.
The reason that my script doesn't leave mount to figure
out the file system type is because of the desire to adjust
mount options depending on the file system type. Alessandro
Fiorino's modifications to my script uses disktype to
retrieve the fs type and set appropriate mount options.
For example: don't bother setting uid and gid options for
ext2/ext3 - only do this for non Linux file systems.
Cheers,
Michael
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Re linux-hotplug-devel Re USBdesktop integration - how to guess
2004-02-13 12:39 Re linux-hotplug-devel Re USBdesktop integration - how to guess /dev/sd* when Michael Hamilton
@ 2004-02-13 12:54 ` Wout Mertens
2004-02-13 22:08 ` linux-hotplug-devel Re USBdesktop integration - how to guess /dev/sd* when Michael Hamilton
1 sibling, 0 replies; 3+ messages in thread
From: Wout Mertens @ 2004-02-13 12:54 UTC (permalink / raw)
To: linux-hotplug
Tomorrow at 01:39, Michael Hamilton ponderously produced:
> On Sat, 14 Feb 2004 00:11, Wout Mertens wrote:
> > Interesting... Where do I assume 1 partition and fat? I just let mount
> > figure it out. With Linux 2.4 I iterate through all partitions, and
> > with 2.6, the block event takes care of that.
> >
> > Apart from that, any devfs-isms that might be there should be easily
> > fixable. Why don't you just give it a shot? :)
> >
> > Wout.
> >
> > Tomorrow at 00:01, Michael Hamilton wrote:
> >>...
>
> I just lept to that assumption from the comments in the 2.4
> version
>
> # TODO use fdisk to figure out partitions and types
>
> and also from the loading and unloading of the vfat module.
> I should have read the script though more thouroughly.
> Sorry about that.
No problem. The script is one huge hack anyway. I hoped the "real"
solution would be there by now, but apparantly nobody but us cares about
automounting :)
> But, I also can't see how
>
> ls /dev/scsi/host$SCSI/
>
> in the 2.4 version can be made to work on Redhat 9. But I guess
> I could merge some code from my stuff to get the same effect.
Maybe
hosts=( a b c d e f g ) # etc
idx=$(( $SCSI + 1 ))
ls /dev/sd${hosts[$idx]}
? Not tested, though.
> Also under 2.6 my $DEVPATH contains more than the three parts
> your scripts are looking for, eg /devices/pci0000:00/0000:00:11.2/usb3/3-2/3-2:1.0
Uhm
my DEVPATH looks like /block/sdc/sdc1...
Hmmm. Did you put it in /etc/hotplug.d/block ?
I think it gets passed the same things that get passed to /sbin/hotplug,
but I'm not sure. I only have one system to test this on :)
> So I was a bit mystified. Getting from the above to
> /dev/sda /dev/sdb seems to be very difficult without using
> something like sg_map. Perhaps I'm wrong to be sticking with
> the old /dev/sd[abc...] stuff, and for sticking with Redhat
Well, the Linux folx seem to think that /dev/discs/... etc was a bad
idea and are now going back to /dev/sd... . Whatever. See the udev
lists. But this means that you should not worry :)
> and its hotplug - but I was hoping that I could use 2.6 without
> any major changes. I have pretty much achieved this goal -
> except that I have to install another utility, sg_map.
Hmmm? What's that?
> The reason that my script doesn't leave mount to figure
> out the file system type is because of the desire to adjust
> mount options depending on the file system type. Alessandro
> Fiorino's modifications to my script uses disktype to
> retrieve the fs type and set appropriate mount options.
> For example: don't bother setting uid and gid options for
> ext2/ext3 - only do this for non Linux file systems.
Cool! The reason mine doesn't is because I was too lazy to implement
something like that. :) I also got a patch from someone to populate
/etc/fstab, which is really cool, but I didn't get around applying it
yet. If he reads it, I'm really sorry :)
Wout.
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: linux-hotplug-devel Re USBdesktop integration - how to guess /dev/sd* when
2004-02-13 12:39 Re linux-hotplug-devel Re USBdesktop integration - how to guess /dev/sd* when Michael Hamilton
2004-02-13 12:54 ` Re linux-hotplug-devel Re USBdesktop integration - how to guess Wout Mertens
@ 2004-02-13 22:08 ` Michael Hamilton
1 sibling, 0 replies; 3+ messages in thread
From: Michael Hamilton @ 2004-02-13 22:08 UTC (permalink / raw)
To: linux-hotplug
On Sat, 14 Feb 2004 01:54, Wout Mertens wrote:
> No problem. The script is one huge hack anyway. I hoped the "real"
> solution would be there by now, but apparantly nobody but us cares about
> automounting :)
You're 100% echoing my thoughts and feelings concerning my
scripts. Hopefully our exchange will prompt some interest
in this area and contribute to the requirements for a
complete solution at both the kernel, utils, and desktop level.
>
> > But, I also can't see how
> >
> > ls /dev/scsi/host$SCSI/
> >
> > in the 2.4 version can be made to work on Redhat 9. But I guess
> > I could merge some code from my stuff to get the same effect.
>
> Maybe
>
> hosts=( a b c d e f g ) # etc
> idx=$(( $SCSI + 1 ))
> ls /dev/sd${hosts[$idx]}
>
> ? Not tested, though.
I was doing something like that - but /dev/sda, /dev/sdb
sequence can vary independently from the number sequence.
In 2.4 I used the trick of unloading modules to reset the
sequence - but this doesn't work in 2.6 - and this was a buggy
hack that only worked if one device was plugged in at any
given time and it wouldn't work if someone had
non-usb scsi disks.
http://www.torque.net/sg/u_index.html
> > Also under 2.6 my $DEVPATH contains more than the three parts
> > your scripts are looking for, eg
> > /devices/pci0000:00/0000:00:11.2/usb3/3-2/3-2:1.0
>
> Uhm
>
> my DEVPATH looks like /block/sdc/sdc1...
>
> Hmmm. Did you put it in /etc/hotplug.d/block ?
>
> I think it gets passed the same things that get passed to /sbin/hotplug,
> but I'm not sure. I only have one system to test this on :)
I think it might be because I'm still on the original
Redhat 9 hotplug. Maybe I should try the latest one.
> > So I was a bit mystified. Getting from the above to
> > /dev/sda /dev/sdb seems to be very difficult without using
> > something like sg_map. Perhaps I'm wrong to be sticking with
> > the old /dev/sd[abc...] stuff, and for sticking with Redhat
>
> Well, the Linux folx seem to think that /dev/discs/... etc was a bad
> idea and are now going back to /dev/sd... . Whatever. See the udev
> lists. But this means that you should not worry :)
I should read up on udev - esp now I have 2.6 running.
> > and its hotplug - but I was hoping that I could use 2.6 without
> > any major changes. I have pretty much achieved this goal -
> > except that I have to install another utility, sg_map.
>
> Hmmm? What's that?
See above.
> > The reason that my script doesn't leave mount to figure
> > out the file system type is because of the desire to adjust
> > mount options depending on the file system type. Alessandro
> > Fiorino's modifications to my script uses disktype to
> > retrieve the fs type and set appropriate mount options.
> > For example: don't bother setting uid and gid options for
> > ext2/ext3 - only do this for non Linux file systems.
>
> Cool! The reason mine doesn't is because I was too lazy to implement
> something like that. :) I also got a patch from someone to populate
> /etc/fstab, which is really cool, but I didn't get around applying it
> yet. If he reads it, I'm really sorry :)
Fstab is too important at boot up, I prefer not to touch it. I
think anything that might frequently edit fstab could be
quite dangerous. What if / is full, or there is a power
loss during the update. Paranoid - I know - but there are
enough users out there to encounter almost any scenario. Maybe
pluggable devices should have their own fsplugtab that could
live somewhere in /var.
Cheers
MIchael.
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2004-02-13 22:08 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-13 12:39 Re linux-hotplug-devel Re USBdesktop integration - how to guess /dev/sd* when Michael Hamilton
2004-02-13 12:54 ` Re linux-hotplug-devel Re USBdesktop integration - how to guess Wout Mertens
2004-02-13 22:08 ` linux-hotplug-devel Re USBdesktop integration - how to guess /dev/sd* when Michael Hamilton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).