Re: letting glabel recognise a media change

Previous thread: Soft update panic while running perl 5.12 tests by Dimitry Andric on Wednesday, September 29, 2010 - 7:32 am. (5 messages)

Next thread: Re: Examining the VM splay tree effectiveness by Roman Divacky on Thursday, September 30, 2010 - 10:24 am. (11 messages)
From: Alexander Best
Date: Wednesday, September 29, 2010 - 2:12 pm

hi there,

i wanted to ask if it would be possible to asjust glabel so that e.g. inserting
a new media into a dvd-drive gets recognised and glabel displays the lablel
right away.

right now i use this shell alias to work around this issue:

mdvd='sh -c ": 3>/dev/dvd" ; mount /media/dvd/ && cd /media/dvd/'

cheers.
alex

-- 
a13x
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Andriy Gapon
Date: Wednesday, September 29, 2010 - 2:45 pm

Yes, of course, as soon as we have in kernel a programmatic way to know that
media as changed.
We don't have one right now...

-- 
Andriy Gapon
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Matthew Jacob
Date: Wednesday, September 29, 2010 - 3:28 pm

What announcement API would you like to add?

If something like that was in place, I assure you that things would 
start to use it very quickly.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Ivan Voras
Date: Thursday, September 30, 2010 - 2:59 am

It doesn't have to be a heavy "announcement API". Basically, something 
would have to re-trigger GEOM tasting on existing devices, probably by 
marking them "spoiled" first.

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Matthew Jacob
Date: Thursday, September 30, 2010 - 5:45 am

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Andriy Gapon
Date: Thursday, September 30, 2010 - 4:22 am

Not sure what kind of API you mean and if anything really needs to be added.

I am not sure about this.
Because, e.g. I don't see an easy way to know that media is changed in scsi_cd
driver.  That is, without polling.  I don't consider polling to be an easy way for
a number of reasons.

-- 
Andriy Gapon
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Matthew Jacob
Date: Thursday, September 30, 2010 - 5:53 am

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Andriy Gapon
Date: Thursday, September 30, 2010 - 1:49 pm

In fact, I am not sure anymore :-)
I had in mind some technical difficulties (like potential races with "normal"
usage), but I think that they all are not very hard to overcome.
Another question I had was how to poll, i.e. what command(s) to issue to cover
different possibilities and hardware capabilities.



-- 
Andriy Gapon
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Alexander Motin
Date: Thursday, September 30, 2010 - 10:46 am

SATA specification defines concept of Asynchronous Notification. It is
already used by port multipliers to report about PHY events. It is also
supposed to be used by CD drives to report media change. I haven't seen
such devices yet, but hope they may appear sometimes.

And even without AN support it would be nice to implement proper
handling for SCSI "UA - media changed" errors within CAM. It still won't
be perfect without using polling, but probably still something.

-- 
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Andriy Gapon
Date: Thursday, September 30, 2010 - 1:45 pm

Would this require some reverse-path from SIM driver to peripheral driver to

I agree.

-- 
Andriy Gapon
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Alexander Motin
Date: Thursday, September 30, 2010 - 2:00 pm

Yes we do. SATA PMP driver (it looks like usual peripheral driver from
this point) already receives and handles AC_SCSI_AEN messages sent to it
via xpt_async() mechanism.

-- 
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Pawel Jakub Dawidek
Date: Sunday, October 10, 2010 - 8:53 am

I'd like to know the original reason why CD device is represented by
GEOM provider and not CD media. For my naive thinking CD media should be
GEOM provider that we taste once the media is inserted and orphan once
the media is removed. I don't see any reasons for CD device to be useful
GEOM provider, but maybe I'm overlooking something.

Poul-Henning or Soren, do you remember who made and why this design choice?

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
From: Alexander Motin
Date: Sunday, October 10, 2010 - 1:55 pm

SCSI drivers receive no notification on media insertion. Somebody should
poll device. At this moment it is handled by consumers. Indeed not sure
it is the best idea. If we want driver to bother with this polling - we
may do as you propose. Actually in sdhci(4) driver I am doing this way -
mmcsdX device appears when card inserted and disappears on removal.

I think first thing that may brake if there will be no cdX device -
loading the media with some commands. Also it may be non-intuitive that
drive is present, but disk is not registered in GEOM.

-- 
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: John Baldwin
Date: Monday, October 11, 2010 - 8:03 am

With CD drives you are also rather stuck in that the existing ABI for
controlling CD drives (e.g. ioctls in 3rd party software to eject a CD) are
done on the /dev/cdX device.  Ideally enclosures for removable media would
be separate devices from the removable media itself, but a lot of existing
software for CD's would break if this changes now.

-- 
John Baldwin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Pawel Jakub Dawidek
Date: Monday, October 11, 2010 - 1:11 pm

Right, but I still wonder if we could execute provider orphan and
retaste on various events like media insertion or removal. If media is
removed we orphan provider and recreate it, which will trigger retaste,
and this is fine there will be nothing to read from or write to (we will
simply return errors as we do now, I think). This way we nicely
co-operate with GEOM, but also with other tools that don't require media
to be present (if there is no media devfs entry still exists and handles
ioctls, it just return errors on read requests).

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
From: Andriy Gapon
Date: Tuesday, October 12, 2010 - 5:50 am

I think nobody would disagree with that approach.
The issue is to reliably detect those events without interfering with normal usage
of the device.


-- 
Andriy Gapon
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: John Baldwin
Date: Tuesday, October 12, 2010 - 6:08 am

Oh, I would be fine with that.  I was just explaining the legacy reasons for
why we can't do the obvious thing and have separate devices for media and
media holders.

-- 
John Baldwin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Søren Schmidt
Date: Monday, October 11, 2010 - 12:46 am

Think burning data on empty media.

-Søren

"Any sufficiently advanced technology is indistinguishable from magic."
--

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Doug Barton
Date: Thursday, September 30, 2010 - 2:07 pm

To what extent is HAL relevant here? I was sort of ambivalent about 
using it in FreeBSD, but my recent experimentation with ubuntu is 
starting to change my mind.


Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Doug Barton
Date: Thursday, September 30, 2010 - 2:38 pm

Sorry, I'm being too terse. What I'm saying is that we have an existing 
"notifications" model that third party apps already know how to deal 
with. If we're considering developing a notifications model of our own 
then we are well served by looking at the work that has gone before 
(without violating copyright issues, yadda yadda).


hth,

Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Garrett Cooper
Date: Thursday, September 30, 2010 - 3:20 pm

The problem is that the current system proposed for Device Kit is
based on file system notification. I know we can do this with kqueues
to some degree, but we do some of our best work via sysctls, and using
other methods of attack, so it would be nice if these were
`abstracted' out into generic events with OS specific callback
handlers.
    Anyhow, just something to toss around, but honestly apart from the
disc tasting I see via hald whenever I insert a CD or DVD, I could
really care less about that functionality, and it could be just as
easily implemented via some other mechanism, similar to what we
already have in devd, or something more kernel centric like others
have suggested before with geom.
Thanks!
-Garrett
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Doug Barton
Date: Thursday, September 30, 2010 - 8:41 pm

I'm not a kernel developer so I'm not going to tell anyone _how_ to 
implement the internals of this idea. My point is that if we're going to 
implement something that the API should be compatible so that all of the 
client software that already works with HAL doesn't have to be 
rewritten, patched, or abandoned.


Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Dimitry Andric
Date: Thursday, September 30, 2010 - 2:29 pm

Please read this first:  https://wiki.ubuntu.com/Halsectomy  :)
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Doug Barton
Date: Thursday, September 30, 2010 - 2:34 pm

Right, especially the bits about moving the functionality into the kernel.


Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Previous thread: Soft update panic while running perl 5.12 tests by Dimitry Andric on Wednesday, September 29, 2010 - 7:32 am. (5 messages)

Next thread: Re: Examining the VM splay tree effectiveness by Roman Divacky on Thursday, September 30, 2010 - 10:24 am. (11 messages)