linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Hamilton <michael@actrix.gen.nz>
To: linux-hotplug@vger.kernel.org
Subject: Re: linux-hotplug-devel  Re USBdesktop integration - how to guess /dev/sd* when
Date: Fri, 13 Feb 2004 22:08:59 +0000	[thread overview]
Message-ID: <200402141107.38219.michael@actrix.gen.nz> (raw)
In-Reply-To: <200402140139.00352.michael@actrix.gen.nz>

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

      parent reply	other threads:[~2004-02-13 22:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=200402141107.38219.michael@actrix.gen.nz \
    --to=michael@actrix.gen.nz \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

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

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