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 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?))
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?))
[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?))
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?))
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?))
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?))
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:
> 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?))
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: > 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?))
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_
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 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: >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
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
devfs deficiencies (was: devfs and Vinum (was: any -current && vinum problems?))
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. In any case, what devfs has is support for names with / in them. It violates POLA and causes serious problems in third party software. I think that you should implement subdirectories. >> it was a primary design goal in the previous devfs and its >> disappearance caught me by surprise. (the support I mean) > > > The ability to not panic left, right and centre was a primary > design goal of this devfs and its absense in the previos devfs > caught be by surprise. (The lack of support as well). > 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. And in general, can we stop the high incidence of mud-slinging we've seen on the lists lately? 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
