|
Home > Archive > Unix administration > June 2007 > multple char devs for single physical dev
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
multple char devs for single physical dev
|
|
| Harshal 2007-05-31, 1:21 pm |
| Hello,
I have a system where I have a character device and
corrosponding block device. can I create one more character
device? my aim is to get (on HPUX)
#ioscan -funC disk | grep dev | head -1
/dev/dsk/c0t0d0 /dev/rdsk/c0t0d0 /dev/rdsk/some_name001
Regards,
Harshal
| |
| Doug Freyburger 2007-05-31, 7:24 pm |
| Harshal <p.hars...@gmail.com> wrote:
>
> I have a system where I have a character device and
> corrosponding block device. can I create one more character
> device?
Sure you can do that. The question is why you would want to
and can you explain why it's a bad idea. Once you can
explain why it's a bad idea then you're qualified to actually
do it - Know the downside and go in knowing or have no idea
and go in blind.
Chances are you actually want to do something you have not
specified and there's a rational way to do it that you haven't
thought of yet. Instead so far you've come up with this scheme
and you haven't noticed the serious problems the scheme
involves.
> my aim is to get (on HPUX)
>
> #ioscan -funC disk | grep dev | head -1
>
> /dev/dsk/c0t0d0 /dev/rdsk/c0t0d0 /dev/rdsk/some_name001
Using ln -s to make a symlink is probably the method with the
fewest bad side effects. Since the original device is still "the"
device there's no confusion in the kernel as to where it's data
goes.
Using mknod using the major and minor device numbers from
ls -l is probably the method with the most bad side effects.
When an interrupt come in for that device, what's the behavior
of handling out the data to the two inodes? Far too likely to
be not what you want.
To know that you're qualified to actually try such a stunt
here's the question to answer: Explain what happens to data
coming from an interupt if you use ln to make a hard link
instead of ln -s to make a symlink.
So what is it you're actually trying to acheive?
| |
| Harshal 2007-06-01, 1:21 pm |
| On Jun 1, 12:38 am, Doug Freyburger <dfrey...@yahoo.com> wrote:
> Harshal <p.hars...@gmail.com> wrote:
>
>
> Sure you can do that. The question is why you would want to
> and can you explain why it's a bad idea. Once you can
> explain why it's a bad idea then you're qualified to actually
> do it - Know the downside and go in knowing or have no idea
> and go in blind.
>
> Chances are you actually want to do something you have not
> specified and there's a rational way to do it that you haven't
> thought of yet. Instead so far you've come up with this scheme
> and you haven't noticed the serious problems the scheme
> involves.
>
>
>
>
> Using ln -s to make a symlink is probably the method with the
> fewest bad side effects. Since the original device is still "the"
> device there's no confusion in the kernel as to where it's data
> goes.
>
> Using mknod using the major and minor device numbers from
> ls -l is probably the method with the most bad side effects.
> When an interrupt come in for that device, what's the behavior
> of handling out the data to the two inodes? Far too likely to
> be not what you want.
>
This is exact option I was thinking of but not sure of its outcomes.
> To know that you're qualified to actually try such a stunt
> here's the question to answer: Explain what happens to data
> coming from an interupt if you use ln to make a hard link
> instead of ln -s to make a symlink.
only one of the char devs gets registered.
>
> So what is it you're actually trying to acheive?
I have one customer who has the setup like this, and I have to
simulated that setup here in our lab, as there are some issues that we
are facing in our product. I got the ioscan output from that
customer. so thought may be creating a char dev might help.
|
|
|
|
|