Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
Julian Elischer wrote: If it is to be counted as my only achivement on -core that I timed out SLICE and DEVFS, I'll still be proud of what I did there. Well you timed them out without askling the developer what he had in the wings and that was more than impolite, it was stupid, because most of the shortcomings of devfs and SLICE had been solved and all I was waiting for was the CAM switchover, so that I didn't have to do everything twice. It's not his only accomplishment. He also helped kill LFS by moving it to the attic, and killed block devices, even though we know that the Apple DVD code needed both block and character versions of a disk device to support the DVDFS and the ISO9660FS at the same time. The block device issue is a sore point, since it's now practically impossible to generate tapes with odd byte boundaries instead of full records (thus causing an implicit conv=sysnc, even if you don't want one). I seem to remember you supporting him killing block devices... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
In message [EMAIL PROTECTED], Ju lian Elischer writes: Well you timed them out without askling the developer what he had in the wings and that was more than impolite, it was stupid, because most of the shortcomings of devfs and SLICE had been solved and all I was waiting for was the CAM switchover, so that I didn't have to do everything twice. Yeah, and together with Terrys VFS patches that would have made Microsoft bankrupt overnight. Sure... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
[Format recovered--see http://www.lemis.com/email/email-format.html] Your MUA wraps incorrectly. On Friday, 17 August 2001 at 9:16:59 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Julian Elischer writes: Well you timed them out without askling the developer what he had in the wings and that was more than impolite, it was stupid, because most of the shortcomings of devfs and SLICE had been solved and all I was waiting for was the CAM switchover, so that I didn't have to do everything twice. Yeah, and together with Terrys VFS patches that would have made Microsoft bankrupt overnight. People, could we please stop this kind of nastiness? Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
Poul-Henning Kamp wrote: Julian Elischer writes: Well you timed them out without askling the developer what he had in the wings and that was more than impolite, it was stupid, because most of the shortcomings of devfs and SLICE had been solved and all I was waiting for was the CAM switchover, so that I didn't have to do everything twice. Yeah, and together with Terrys VFS patches that would have made Microsoft bankrupt overnight. Sure... Hardly; many of my VFS patches were designed to make the code more portable... for instance, to Windows 95, where they ran without problems starting ~1995/1996... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Fri, 17 Aug 2001, Terry Lambert wrote: Poul-Henning Kamp wrote: Julian Elischer writes: Well you timed them out without askling the developer what he had in the wings and that was more than impolite, it was stupid, because most of the shortcomings of devfs and SLICE had been solved and all I was waiting for was the CAM switchover, so that I didn't have to do everything twice. you don't even think it was implolite? Yeah, and together with Terrys VFS patches that would have made Microsoft bankrupt overnight. Sure... Hardly; many of my VFS patches were designed to make the code more portable... for instance, to Windows 95, where they ran without problems starting ~1995/1996... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
In message [EMAIL PROTECTED], Ju lian Elischer writes: On Fri, 17 Aug 2001, Terry Lambert wrote: Poul-Henning Kamp wrote: Julian Elischer writes: Well you timed them out without askling the developer what he had in the wings and that was more than impolite, it was stupid, because most of the shortcomings of devfs and SLICE had been solved and all I was waiting for was the CAM switchover, so that I didn't have to do everything twice. you don't even think it was implolite? The only thing I found really impolite was that the old-core left the thing hanging in the air for several years. It's OK to have things hanging in the air if it is done on purpose, but it is certainly not OK if it hangs there as function of a somebody-elses-problem field like in this case. I certainly didn't find it any more impolite than committing a barely working or even non-working prototype into the CVS tree and then abandonning it once it worked OK for my immediate needs. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Thursday, 16 August 2001 at 6:36:45 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Greg Lehey writes: On Wednesday, 15 August 2001 at 19:17:47 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: the lack of subdirectory support is a pitty. There is support for subdirectories: ls -la /dev/fd What am I supposed to see there? I get three character devices, all mounted on /dev directly. Uhm, have you forgotten how ls(1) works ? No. Try this then: ls -lad /dev/fd /dev/fd/[012] Hmm. Strange. Last time I looked, I thought I had /dev/fd0, /dev/fd1 and /dev/fd2. But I've booted a new kernel since that attempt. In view of the fact that this thread is about deficiencies in your devfs, this is particularly uncalled for. One of the reasons that Julian's devfs never got debugged was that you had made it very clear from the start that it would be removed. History being rewritten eh ? I spent 3+ years trying to argue his DEVFS should be made default! They must have been before I met you, then. My very vivid recollection was that I met you at USENIX in New Orleans on 19 June 1998, and the very first thing you said was What does Vinum do about DEVFS? Don't use it, it's going away. We (you, Justin Gibbs, Jonathan Bresler, and I, maybe also one other person, but not Julian, whom you wouldn't let participate) then found an empty room and we discussed the matter. It was an interesting first impression. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
In message [EMAIL PROTECTED], Greg Lehey writes: ls -la /dev/fd What am I supposed to see there? I get three character devices, all mounted on /dev directly. Uhm, have you forgotten how ls(1) works ? No. Try this then: ls -lad /dev/fd /dev/fd/[012] Hmm. Strange. Last time I looked, I thought I had /dev/fd0, /dev/fd1 and /dev/fd2. But I've booted a new kernel since that attempt. Well that must have been a very very old kernel then, at least if you intend to insist on blaiming DEVFS. See cvs logs. History being rewritten eh ? I spent 3+ years trying to argue his DEVFS should be made default! They must have been before I met you, then. My very vivid recollection was that I met you at USENIX in New Orleans on 19 June 1998, and the very first thing you said was What does Vinum do about DEVFS? Don't use it, it's going away. We (you, Justin Gibbs, Jonathan Bresler, and I, maybe also one other person, but not Julian, whom you wouldn't let participate) then found an empty room and we discussed the matter. It was an interesting first impression. A lot of people, you included, have never quite realized, or maybe just forgotten exactly just how long time Julians DEVFS sat in our tree while people bickered about things like persistence and random panics: src/sys/miscfs/devfs/devfs_vfsops.c: Revision 1.1 Thu Apr 20 03:31:31 1995 UTC (6 years, 3 months ago) by julian After 3 years I gave up on the hope that it would ever be fixed well enough to become politically acceptable. After 6 years I removed it. A quick script run on the cvs tree paints this picture of number of commits to src/sys/miscfs/devfs per year: julian phk other 199556 3 15 199620 10 43 199721 13 16 199815 2 24 1999 6 15 30 2000 0 16 8 2001 0 1 7 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Thu, 16 Aug 2001, Greg Lehey wrote:
On Thursday, 16 August 2001 at 6:36:45 +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Greg Lehey writes:
In view of the fact that this thread is about deficiencies in your
devfs, this is particularly uncalled for. One of the reasons that
Julian's devfs never got debugged was that you had made it very clear
from the start that it would be removed.
History being rewritten eh ? I spent 3+ years trying to argue his
DEVFS should be made default!
They must have been before I met you, then. My very vivid
recollection was that I met you at USENIX in New Orleans on 19 June
1998, and the very first thing you said was What does Vinum do about
DEVFS? Don't use it, it's going away. We (you, Justin Gibbs,
He first sold it to me on Tue, 6 Dec 1994 15:41:55 -0800 (PST). It
seemed like a good idea at the time :-). That sure was a different
time. ref but no freefall (?)...
From [EMAIL PROTECTED] Wed Dec 7 10:45:03 1994
Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by godzilla.zeta.org.au
(8.6.9/8.6.9) with ESMTP id KAA24274 for [EMAIL PROTECTED]; Wed, 7 Dec 1994 10:42:08
+1100
Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id PAA10093; Tue, 6 Dec
1994 15:41:55 -0800
From: Poul-Henning Kamp [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]
Subject: Re: vn.c,v
To: [EMAIL PROTECTED] (Bruce Evans)
Date: Tue, 6 Dec 1994 15:41:55 -0800 (PST)
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED] from Bruce Evans at Dec
7, 94 09:50:43 am
Content-Type: text
Content-Length: 4320
Status: RO
I really miss these functions in the kernel:
void * dev_get_private __P((dev_t));
...
I talked to Julian about his devfs and the above changes might be fallout
from that when all is said and done.
I don't see how you can access the devices without putting them in the
file system. How complete is devfs? How can it handle all the different
meanings of minor numbers? Things like ttyd0 vs cuaa0 probably should
use different majors anyway.
I'm terrible at explaning this stuff, but I will do an attempt now. If
this looks like complete rubbish to you, then I probably didn't explain it
too well, and have better try again.
I have cc'ed the arch list on this, as well as Julian, since it came out
to be quite a general description.
The devfs idea is to implement a filesystem, where the devices present
reflect what the device-drivers told us that they have found, without having
to much around with MAKEDEV,mknod,cdevsw and bdevsw.
So for instance, the fd driver probes and finds a 720 Kb 3.5 drive it would
call something like
/* /dev/???, major, minor */
devfs_register(fd0, 2, 0);
devfs_register(fd0.360, 2, 8);
devfs_register(fd0.720, 2, 7);
...
(Of course the fd0 string would need to be built dynamicly somehow, and
probably we should apply some kind of '%' escapes to help do so)
And the entries will show up in /dev because the devfs maintains a table
fd0 -- (2,0)
Pow! there goes mknod and MAKEDEV.
The devfs doesn't interpret the dev_t's it only maintains the
/dev/foo - dev_t association.
Doing it this way, the entire concept of major/minor numbers can
be dropped from the plan, because a dev_t could just as well be a void *
now.
By having the devfs take care of the registration, the cdevsw/bdevsw
got obsolete, because the device-drivers themselves know their names now,
and the major/minor was only a way to pass information from mknod to the
driver.
This means that a device-driver could register it's softc structure
directly with the devfs, instead of having to look up from the dev_t first.
To make it convenient, we would make the dev_t this instead:
typedef struct {
char*d_name;
struct driver *d_driver;
void*d_private_1;
unsigned long d_private_2;
} * dev_t;
#define dev_private1(dev) (dev-d_private_1)
#define dev_private2(dev) (dev-d_private_2)
#define dev_name(dev) (dev-d_name)
and the register would look like this in fd.c:
/sys/sys/something.h:
struct dev_driver {
char*dev_name;
int (*dev_open) __P((...));
int (*dev_close)__P((...));
int (*dev_ioctl)__P((...));
...
}
fd.c:
/* this is in global scope */
static struct dev_driver {
fd,
fd_open,
fd_close
...
} fd_driver;
/* Ha! we found a drive */
fsc = malloc (sizeof struct fd_softc, M_DEVBUF, M_WAITOK);
fsc-foo = this;
fsc-bar = that;
...
/*/dev/???, private_1, private_2 */
devfs_register(fd_driver, fd0,
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Thu, 16 Aug 2001, Poul-Henning Kamp wrote: After 3 years I gave up on the hope that it would ever be fixed well enough to become politically acceptable. After 6 years I removed it. A quick script run on the cvs tree paints this picture of number of commits to src/sys/miscfs/devfs per year: julian phk other 199556 3 15 199620 10 43 199721 13 16 199815 2 24 --at this point SOS and PHK delete half of devfs... Both are in core.. Julian feels he has no avenue of recourse and gives up..-- 1999 6 15 30 2000 0 16 8 2001 0 1 7 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
In message [EMAIL PROTECTED], Ju lian Elischer writes: A quick script run on the cvs tree paints this picture of number of commits to src/sys/miscfs/devfs per year: julian phk other 199556 3 15 199620 10 43 199721 13 16 199815 2 24 --at this point SOS and PHK delete half of devfs... Both are in core.. Julian feels he has no avenue of recourse and gives up..-- if (!strcmp(DEVFS, SLICE)) return (ECONFUSED); Julian, you had four years, during which you didn't even manage to make half of the commits made to the DEVFS code during that period. If it is to be counted as my only achivement on -core that I timed out SLICE and DEVFS, I'll still be proud of what I did there. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Thu, 16 Aug 2001, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: A quick script run on the cvs tree paints this picture of number of commits to src/sys/miscfs/devfs per year: julian phk other 199556 3 15 199620 10 43 199721 13 16 199815 2 24 --at this point SOS and PHK delete half of devfs... Both are in core.. Julian feels he has no avenue of recourse and gives up..-- if (!strcmp(DEVFS, SLICE)) return (ECONFUSED); Julian, you had four years, during which you didn't even manage to make half of the commits made to the DEVFS code during that period. If it is to be counted as my only achivement on -core that I timed out SLICE and DEVFS, I'll still be proud of what I did there. Well you timed them out without askling the developer what he had in the wings and that was more than impolite, it was stupid, because most of the shortcomings of devfs and SLICE had been solved and all I was waiting for was the CAM switchover, so that I didn't have to do everything twice. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Thu, 16 Aug 2001, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: A quick script run on the cvs tree paints this picture of number of commits to src/sys/miscfs/devfs per year: julian phk other 199556 3 15 199620 10 43 199721 13 16 199815 2 24 --at this point SOS and PHK delete half of devfs... Both are in core.. Julian feels he has no avenue of recourse and gives up..-- if (!strcmp(DEVFS, SLICE)) return (ECONFUSED); Julian, you had four years, during which you didn't even manage to make half of the commits made to the DEVFS code during that period. devfs and SLICE were interdependent. By deleting SLICE you basically stopped devfs from being useful in the way I wanted it to be useful and you declared that devfs was also marked for death. In My mind SLICE and DEVFS were two parts of the same project. If it is to be counted as my only achivement on -core that I timed out SLICE and DEVFS, I'll still be proud of what I did there. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Thu, 16 Aug 2001, Poul-Henning Kamp wrote: Julian feels he has no avenue of recourse and gives up..-- if (!strcmp(DEVFS, SLICE)) return (ECONFUSED); Julian, you had four years, during which you didn't even manage to make half of the commits made to the DEVFS code during that period. If it is to be counted as my only achivement on -core that I timed out SLICE and DEVFS, I'll still be proud of what I did there. Umm, your timeouts are very strange - you're timed out too quickly in my case. Of course, you're talked something about that GEOM stuff will be committed in July (of 2000) and it needs devfs. But we didn't see it even now. Well, I'm don't mind about waste of my time spent on a design of new devfs. But one can make corresponding conclusions about your timeouts ... -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
[snip] And in general, can we stop the high incidence of mud-slinging we've seen on the lists lately? Here, here! Brandon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
In message [EMAIL PROTECTED], Greg Lehey writes: On Wednesday, 15 August 2001 at 19:17:47 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: the lack of subdirectory support is a pitty. There is support for subdirectories: ls -la /dev/fd What am I supposed to see there? I get three character devices, all mounted on /dev directly. Uhm, have you forgotten how ls(1) works ? Try this then: ls -lad /dev/fd /dev/fd/[012] In view of the fact that this thread is about deficiencies in your devfs, this is particularly uncalled for. One of the reasons that Julian's devfs never got debugged was that you had made it very clear from the start that it would be removed. History being rewritten eh ? I spent 3+ years trying to argue his DEVFS should be made default! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
