login
Search
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"
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"
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"
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"
_______________________________________________ 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"
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"
_______________________________________________ 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"
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"
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"
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"
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"
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!
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"
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"
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!
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"
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"
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"
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"
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"
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"
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"
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"
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"
