[PATCH] Cygwin: Provide more COM devices

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] Cygwin: Provide more COM devices

Achim Gratz

This was requested on IRC.

From a80b1c9ba67f94237948e85ad2dee744cdfbdcad Mon Sep 17 00:00:00 2001
From: Achim Gratz <[hidden email]>
Date: Sun, 20 Oct 2019 15:23:04 +0200
Subject: [PATCH] Cygwin: provide more COM devices

* winsup/cygwin/devices.cc: Add another 64 COM devices since Windows
  likes to create lots of these over time (one per identifiable device
  and USB port).
---
 winsup/cygwin/devices.cc | 64 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 64 insertions(+)

diff --git a/winsup/cygwin/devices.cc b/winsup/cygwin/devices.cc
index 2e31ca366..7a57459d8 100644
--- a/winsup/cygwin/devices.cc
+++ b/winsup/cygwin/devices.cc
@@ -798,6 +798,70 @@ const _RDATA _device dev_storage[] =
   {"/dev/ttyS61", BRACK(FHDEV(DEV_SERIAL_MAJOR, 61)), "\\??\\COM62", exists_ntdev, S_IFCHR, true},
   {"/dev/ttyS62", BRACK(FHDEV(DEV_SERIAL_MAJOR, 62)), "\\??\\COM63", exists_ntdev, S_IFCHR, true},
   {"/dev/ttyS63", BRACK(FHDEV(DEV_SERIAL_MAJOR, 63)), "\\??\\COM64", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS64", BRACK(FHDEV(DEV_SERIAL_MAJOR, 64)), "\\??\\COM65", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS65", BRACK(FHDEV(DEV_SERIAL_MAJOR, 65)), "\\??\\COM66", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS66", BRACK(FHDEV(DEV_SERIAL_MAJOR, 66)), "\\??\\COM67", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS67", BRACK(FHDEV(DEV_SERIAL_MAJOR, 67)), "\\??\\COM68", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS68", BRACK(FHDEV(DEV_SERIAL_MAJOR, 68)), "\\??\\COM69", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS69", BRACK(FHDEV(DEV_SERIAL_MAJOR, 69)), "\\??\\COM70", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS70", BRACK(FHDEV(DEV_SERIAL_MAJOR, 70)), "\\??\\COM71", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS71", BRACK(FHDEV(DEV_SERIAL_MAJOR, 71)), "\\??\\COM72", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS72", BRACK(FHDEV(DEV_SERIAL_MAJOR, 72)), "\\??\\COM73", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS73", BRACK(FHDEV(DEV_SERIAL_MAJOR, 73)), "\\??\\COM74", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS74", BRACK(FHDEV(DEV_SERIAL_MAJOR, 74)), "\\??\\COM75", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS75", BRACK(FHDEV(DEV_SERIAL_MAJOR, 75)), "\\??\\COM76", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS76", BRACK(FHDEV(DEV_SERIAL_MAJOR, 76)), "\\??\\COM77", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS77", BRACK(FHDEV(DEV_SERIAL_MAJOR, 77)), "\\??\\COM78", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS78", BRACK(FHDEV(DEV_SERIAL_MAJOR, 78)), "\\??\\COM79", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS79", BRACK(FHDEV(DEV_SERIAL_MAJOR, 79)), "\\??\\COM80", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS80", BRACK(FHDEV(DEV_SERIAL_MAJOR, 80)), "\\??\\COM81", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS81", BRACK(FHDEV(DEV_SERIAL_MAJOR, 81)), "\\??\\COM82", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS82", BRACK(FHDEV(DEV_SERIAL_MAJOR, 82)), "\\??\\COM83", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS83", BRACK(FHDEV(DEV_SERIAL_MAJOR, 83)), "\\??\\COM84", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS84", BRACK(FHDEV(DEV_SERIAL_MAJOR, 84)), "\\??\\COM85", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS85", BRACK(FHDEV(DEV_SERIAL_MAJOR, 85)), "\\??\\COM86", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS86", BRACK(FHDEV(DEV_SERIAL_MAJOR, 86)), "\\??\\COM87", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS87", BRACK(FHDEV(DEV_SERIAL_MAJOR, 87)), "\\??\\COM88", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS88", BRACK(FHDEV(DEV_SERIAL_MAJOR, 88)), "\\??\\COM89", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS89", BRACK(FHDEV(DEV_SERIAL_MAJOR, 89)), "\\??\\COM90", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS90", BRACK(FHDEV(DEV_SERIAL_MAJOR, 90)), "\\??\\COM91", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS91", BRACK(FHDEV(DEV_SERIAL_MAJOR, 91)), "\\??\\COM92", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS92", BRACK(FHDEV(DEV_SERIAL_MAJOR, 92)), "\\??\\COM93", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS93", BRACK(FHDEV(DEV_SERIAL_MAJOR, 93)), "\\??\\COM94", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS94", BRACK(FHDEV(DEV_SERIAL_MAJOR, 94)), "\\??\\COM95", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS95", BRACK(FHDEV(DEV_SERIAL_MAJOR, 95)), "\\??\\COM96", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS96", BRACK(FHDEV(DEV_SERIAL_MAJOR, 96)), "\\??\\COM97", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS97", BRACK(FHDEV(DEV_SERIAL_MAJOR, 97)), "\\??\\COM98", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS98", BRACK(FHDEV(DEV_SERIAL_MAJOR, 98)), "\\??\\COM99", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS99", BRACK(FHDEV(DEV_SERIAL_MAJOR, 99)), "\\??\\COM100", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS100", BRACK(FHDEV(DEV_SERIAL_MAJOR, 100)), "\\??\\COM101", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS101", BRACK(FHDEV(DEV_SERIAL_MAJOR, 101)), "\\??\\COM102", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS102", BRACK(FHDEV(DEV_SERIAL_MAJOR, 102)), "\\??\\COM103", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS103", BRACK(FHDEV(DEV_SERIAL_MAJOR, 103)), "\\??\\COM104", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS104", BRACK(FHDEV(DEV_SERIAL_MAJOR, 104)), "\\??\\COM105", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS105", BRACK(FHDEV(DEV_SERIAL_MAJOR, 105)), "\\??\\COM106", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS106", BRACK(FHDEV(DEV_SERIAL_MAJOR, 106)), "\\??\\COM107", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS107", BRACK(FHDEV(DEV_SERIAL_MAJOR, 107)), "\\??\\COM108", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS108", BRACK(FHDEV(DEV_SERIAL_MAJOR, 108)), "\\??\\COM109", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS109", BRACK(FHDEV(DEV_SERIAL_MAJOR, 109)), "\\??\\COM110", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS110", BRACK(FHDEV(DEV_SERIAL_MAJOR, 110)), "\\??\\COM111", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS111", BRACK(FHDEV(DEV_SERIAL_MAJOR, 111)), "\\??\\COM112", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS112", BRACK(FHDEV(DEV_SERIAL_MAJOR, 112)), "\\??\\COM113", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS113", BRACK(FHDEV(DEV_SERIAL_MAJOR, 113)), "\\??\\COM114", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS114", BRACK(FHDEV(DEV_SERIAL_MAJOR, 114)), "\\??\\COM115", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS115", BRACK(FHDEV(DEV_SERIAL_MAJOR, 115)), "\\??\\COM116", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS116", BRACK(FHDEV(DEV_SERIAL_MAJOR, 116)), "\\??\\COM117", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS117", BRACK(FHDEV(DEV_SERIAL_MAJOR, 117)), "\\??\\COM118", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS118", BRACK(FHDEV(DEV_SERIAL_MAJOR, 118)), "\\??\\COM119", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS119", BRACK(FHDEV(DEV_SERIAL_MAJOR, 119)), "\\??\\COM120", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS120", BRACK(FHDEV(DEV_SERIAL_MAJOR, 120)), "\\??\\COM121", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS121", BRACK(FHDEV(DEV_SERIAL_MAJOR, 121)), "\\??\\COM122", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS122", BRACK(FHDEV(DEV_SERIAL_MAJOR, 122)), "\\??\\COM123", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS123", BRACK(FHDEV(DEV_SERIAL_MAJOR, 123)), "\\??\\COM124", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS124", BRACK(FHDEV(DEV_SERIAL_MAJOR, 124)), "\\??\\COM125", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS125", BRACK(FHDEV(DEV_SERIAL_MAJOR, 125)), "\\??\\COM126", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS126", BRACK(FHDEV(DEV_SERIAL_MAJOR, 126)), "\\??\\COM127", exists_ntdev, S_IFCHR, true},
+  {"/dev/ttyS127", BRACK(FHDEV(DEV_SERIAL_MAJOR, 127)), "\\??\\COM128", exists_ntdev, S_IFCHR, true},
   {"/dev/urandom", BRACK(FH_URANDOM), "\\Device\\Null", exists_ntdev, S_IFCHR, true},
   {"/dev/windows", BRACK(FH_WINDOWS), "\\Device\\Null", exists_ntdev, S_IFCHR, true},
   {"/dev/zero", BRACK(FH_ZERO), "\\Device\\Null", exists_ntdev, S_IFCHR, true},
--
2.23.0


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Cygwin: Provide more COM devices

Corinna Vinschen-2
Hi Achim,

On Oct 20 15:27, Achim Gratz wrote:

>
> This was requested on IRC.
>
> >From a80b1c9ba67f94237948e85ad2dee744cdfbdcad Mon Sep 17 00:00:00 2001
> From: Achim Gratz <[hidden email]>
> Date: Sun, 20 Oct 2019 15:23:04 +0200
> Subject: [PATCH] Cygwin: provide more COM devices
>
> * winsup/cygwin/devices.cc: Add another 64 COM devices since Windows
>   likes to create lots of these over time (one per identifiable device
>   and USB port).
> ---
>  winsup/cygwin/devices.cc | 64 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 64 insertions(+)
>
> diff --git a/winsup/cygwin/devices.cc b/winsup/cygwin/devices.cc
> index 2e31ca366..7a57459d8 100644
> --- a/winsup/cygwin/devices.cc
> +++ b/winsup/cygwin/devices.cc
> @@ -798,6 +798,70 @@ const _RDATA _device dev_storage[] =
>    {"/dev/ttyS61", BRACK(FHDEV(DEV_SERIAL_MAJOR, 61)), "\\??\\COM62", exists_ntdev, S_IFCHR, true},
> [...]
That's not the right way to patch this.  devices.cc gets generated from
devices.in by the gendevices script which in turn calls shilka from the
cocom package.  Apart from the struct members you added here, it will
also add some code.  Which, unfortunately, raise the size of devices.cc,
especially troubling the 32 bit version.


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Maintainer

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Cygwin: Provide more COM devices

Achim Gratz
Corinna Vinschen writes:
> That's not the right way to patch this.  devices.cc gets generated from
> devices.in by the gendevices script which in turn calls shilka from the
> cocom package.

Now that you mention it I remember…  :-(

> Apart from the struct members you added here, it will
> also add some code.  Which, unfortunately, raise the size of devices.cc,
> especially troubling the 32 bit version.

So how about we only do this on 64bit as an added bonus for folks who
"get it"?  One particular machine I've recently worked on presented me
with COM144 to connect to, but I consider this to be an anomaly.  But
COM port numbers in the 70…80 range are pretty common on some of the
more heavily used development machines.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Cygwin: Provide more COM devices

Corinna Vinschen-2
On Oct 21 20:10, Achim Gratz wrote:

> Corinna Vinschen writes:
> > That's not the right way to patch this.  devices.cc gets generated from
> > devices.in by the gendevices script which in turn calls shilka from the
> > cocom package.
>
> Now that you mention it I remember…  :-(
>
> > Apart from the struct members you added here, it will
> > also add some code.  Which, unfortunately, raise the size of devices.cc,
> > especially troubling the 32 bit version.
>
> So how about we only do this on 64bit as an added bonus for folks who
> "get it"?
I'm not hot on doing that, and I'm not sure shilka likes ifdef's
inside the %% block.

> One particular machine I've recently worked on presented me
> with COM144 to connect to, but I consider this to be an anomaly.  But
> COM port numbers in the 70…80 range are pretty common on some of the
> more heavily used development machines.

I just checked and changing ttyS%(0-63) to ttyS%(0-127) raises
the size of .text and .rdata by 6.5K and the size of the final DLL
by 7.6K.  That should be ok.  Just provide the patch so there's your
name on it.

ttyS%(0-255) takes another 23K btw.  Even that should be ok, if
the need arises.  Alternatively we could shortcut shilka as for
/dev/sd*, but that involved much bigger numbers.


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Maintainer

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Cygwin: Provide more COM devices

Achim Gratz
Corinna Vinschen writes:
>> So how about we only do this on 64bit as an added bonus for folks who
>> "get it"?
>
> I'm not hot on doing that, and I'm not sure shilka likes ifdef's
> inside the %% block.

OK, then let's forget about that.

>> One particular machine I've recently worked on presented me
>> with COM144 to connect to, but I consider this to be an anomaly.  But
>> COM port numbers in the 70…80 range are pretty common on some of the
>> more heavily used development machines.
>
> I just checked and changing ttyS%(0-63) to ttyS%(0-127) raises
> the size of .text and .rdata by 6.5K and the size of the final DLL
> by 7.6K.  That should be ok.  Just provide the patch so there's your
> name on it.

You mean just the patch to change device.in?  Can do.  If I also need to
re-generate the other files then I'm afraid I won't be able to do it in
the next two weeks, maybe a bit longer.

> ttyS%(0-255) takes another 23K btw.  Even that should be ok, if
> the need arises.  Alternatively we could shortcut shilka as for
> /dev/sd*, but that involved much bigger numbers.

As I said, I don't think that this is common enough, so let's wait until
somebody complains.  Getting rid of the static entries sounds like a
good idea, but that's for later.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Cygwin: Provide more COM devices

Corinna Vinschen-2
On Oct 22 19:36, Achim Gratz wrote:

> Corinna Vinschen writes:
> >> So how about we only do this on 64bit as an added bonus for folks who
> >> "get it"?
> >
> > I'm not hot on doing that, and I'm not sure shilka likes ifdef's
> > inside the %% block.
>
> OK, then let's forget about that.
>
> >> One particular machine I've recently worked on presented me
> >> with COM144 to connect to, but I consider this to be an anomaly.  But
> >> COM port numbers in the 70…80 range are pretty common on some of the
> >> more heavily used development machines.
> >
> > I just checked and changing ttyS%(0-63) to ttyS%(0-127) raises
> > the size of .text and .rdata by 6.5K and the size of the final DLL
> > by 7.6K.  That should be ok.  Just provide the patch so there's your
> > name on it.
>
> You mean just the patch to change device.in?  Can do.

WFM.


Corinna

--
Corinna Vinschen
Cygwin Maintainer

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Cygwin: Provide more COM devices

Achim Gratz

As requested:

From 7908d09f547e0a7a707139d0faaccc151b88024c Mon Sep 17 00:00:00 2001
From: Achim Gratz <[hidden email]>
Date: Tue, 22 Oct 2019 19:50:50 +0200
Subject: [PATCH] Cygwin: provide more COM devices

* winsup/cygwin/devices.in: Provide for 128 COM devices since Windows
  likes to create lots of these over time (one per identifiable device
  and USB port).
---
 winsup/cygwin/devices.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/cygwin/devices.in b/winsup/cygwin/devices.in
index 59f5f00d2..9a42951f6 100644
--- a/winsup/cygwin/devices.in
+++ b/winsup/cygwin/devices.in
@@ -164,7 +164,7 @@ const _device dev_error_storage =
 "/dev/urandom", BRACK(FH_URANDOM), "\\Device\\Null", exists_ntdev, S_IFCHR, =urandom_dev
 "/dev/clipboard", BRACK(FH_CLIPBOARD), "\\Device\\Null", exists_ntdev, S_IFCHR
 "/dev/com%(1-16)d", BRACK(FHDEV(DEV_SERIAL_MAJOR, {$1 - 1})), "\\??\\COM{$1}", exists_ntdev_silent, S_IFCHR
-"/dev/ttyS%(0-63)d", BRACK(FHDEV(DEV_SERIAL_MAJOR, {$1})), "\\??\\COM{$1 + 1}", exists_ntdev, S_IFCHR
+"/dev/ttyS%(0-127)d", BRACK(FHDEV(DEV_SERIAL_MAJOR, {$1})), "\\??\\COM{$1 + 1}", exists_ntdev, S_IFCHR
 ":pipe", BRACK(FH_PIPE), "/dev/pipe", exists_internal, S_IFCHR
 ":fifo", BRACK(FH_FIFO), "/dev/fifo", exists_internal, S_IFCHR
 "/dev/st%(0-127)d", BRACK(FHDEV(DEV_TAPE_MAJOR, {$1})), "\\Device\\Tape{$1}", exists_ntdev, S_IFBLK
--
2.23.0


Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Cygwin: Provide more COM devices

Corinna Vinschen-2
On Oct 22 19:52, Achim Gratz wrote:

>
> As requested:
>
> >From 7908d09f547e0a7a707139d0faaccc151b88024c Mon Sep 17 00:00:00 2001
> From: Achim Gratz <[hidden email]>
> Date: Tue, 22 Oct 2019 19:50:50 +0200
> Subject: [PATCH] Cygwin: provide more COM devices
>
> * winsup/cygwin/devices.in: Provide for 128 COM devices since Windows
>   likes to create lots of these over time (one per identifiable device
>   and USB port).
Pushed with regenerated devices.cc.  I took the liberty to tweak
the log message a bit.  We don't do CVS-style log entries for quite
some time now :)


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Maintainer

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Cygwin: Provide more COM devices

Achim Gratz
In reply to this post by Corinna Vinschen-2
Corinna Vinschen writes:
[…]
> ttyS%(0-255) takes another 23K btw.  Even that should be ok, if
> the need arises.  Alternatively we could shortcut shilka as for
> /dev/sd*, but that involved much bigger numbers.

I've searched for some documentation (anywhere the glob syntax %(1-128)
would turn up, btw?) and I think Cygwin is misusing shilka a bit here.
It's a keyword scanner, so the arithmetically coded parts of the device
shouldn't be targeted at all.  Instead, only the device path prefix
should be searched via the shilka lexer and the rest of the conversion
done in code.  For the disks we might keep the globbing that gets us the
device major part.  That of course means we construct more devices
on-the-fly (or even all of them) and have a much smaller table of static
device entries (which get searched linearly, so in the end that should
be a net speed improvement).



Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Cygwin: Provide more COM devices

Corinna Vinschen-2
On Nov  3 20:13, Achim Gratz wrote:

> Corinna Vinschen writes:
> […]
> > ttyS%(0-255) takes another 23K btw.  Even that should be ok, if
> > the need arises.  Alternatively we could shortcut shilka as for
> > /dev/sd*, but that involved much bigger numbers.
>
> I've searched for some documentation (anywhere the glob syntax %(1-128)
> would turn up, btw?) and I think Cygwin is misusing shilka a bit here.
> It's a keyword scanner, so the arithmetically coded parts of the device
> shouldn't be targeted at all.  Instead, only the device path prefix
> should be searched via the shilka lexer and the rest of the conversion
> done in code.
Sure, fine with me.

> For the disks we might keep the globbing that gets us the
> device major part.  That of course means we construct more devices
> on-the-fly (or even all of them) and have a much smaller table of static
> device entries

I don't think so.  We already construct the numbered devices on the
fly, see fhandler_dev::readdir() and the `exists' test in there,
which translates into on of the exists_* tests in devices.in.

> (which get searched linearly, so in the end that should
> be a net speed improvement).

That in turn would be great.


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Maintainer

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Cygwin: Provide more COM devices

Achim Gratz
In reply to this post by Achim Gratz
Achim Gratz writes:

> Corinna Vinschen writes:
> […]
>> ttyS%(0-255) takes another 23K btw.  Even that should be ok, if
>> the need arises.  Alternatively we could shortcut shilka as for
>> /dev/sd*, but that involved much bigger numbers.
>
> I've searched for some documentation (anywhere the glob syntax %(1-128)
> would turn up, btw?) and I think Cygwin is misusing shilka a bit here.
> It's a keyword scanner, so the arithmetically coded parts of the device
> shouldn't be targeted at all.  Instead, only the device path prefix
> should be searched via the shilka lexer and the rest of the conversion
> done in code.

I've stared at the code for quite some time now and I think I've come up
with something that could work.  I'm chopping the device numbers and
disk names off the end of the device name before feeding into the shilka
lexer.  That creates a lexer with only 29 keywords and much less entries
in the dev_storage array, so it should be much faster to search also,
although I think a hash to access the array via the major device number
would now be feasible.  I think I'll have to extend the _device
structure with one or two more function pointers to deal with putting
the minor numbers back in before handing the result to the caller.  In
principle that could deal with any number of devices that fit into the
device number scheme, but we can still declare certain ranges illegal.

--8<---------------cut here---------------start------------->8---
void
device::parse (const char *s)
{
  size_t len = strlen (s);
  const char *t = s + len; /* points past s */

  /* chop off any trailing digits and leave t pointing to the beginning of that number */
  for (; isdigit (t-1); len--, t--) ;

  if (len > 7 && len < 12 && s[7] == 'd'
      /* Generic check for /dev/sd[a-z] prefix */
      && strncmp (s, DISK_PREFIX, DP_LEN) == 0
      && s[DP_LEN] >= 'a' && s[DP_LEN] <= 'z')
    {
      /* /dev/sd* devices have 8192 entries, given that we support 128 disks
         with up to 64 partitions.  Handling them with shilka raises the size
         of devices.o from ~250K to ~2 Megs.  So we handle them here manually
         to save this space. */
         …
    }
  else
    {
      const _device *dev = KR_find_keyword (s, len);
      if (!dev)
        *this = *fs_dev;
      else
        {
          *this = *dev;
          /* check and process device numbers */
          …
        }
    }
}
--8<---------------cut here---------------end--------------->8---


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Cygwin: Provide more COM devices

Brian Inglis
On 2019-12-14 11:38, Achim Gratz wrote:

s[6] == 'd'?

>   if (len > 7 && len < 12 && s[7] == 'd'
-   if (len > 7 && len < 12 && s[7] == 'd'
+   if (len > 7 && len < 12 && s[DP_LEN - 1] == 'd'
>       /* Generic check for /dev/sd[a-z] prefix */
>       && strncmp (s, DISK_PREFIX, DP_LEN) == 0
>       && s[DP_LEN] >= 'a' && s[DP_LEN] <= 'z')

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Cygwin: Provide more COM devices

Achim Gratz
Brian Inglis writes:
> On 2019-12-14 11:38, Achim Gratz wrote:
>
> s[6] == 'd'?

Indeed.

>>   if (len > 7 && len < 12 && s[7] == 'd'
> -   if (len > 7 && len < 12 && s[7] == 'd'
> +   if (len > 7 && len < 12 && s[DP_LEN - 1] == 'd'

Yes, that's better.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Cygwin: Provide more COM devices

Brian Inglis
In reply to this post by Achim Gratz
On 2019-12-14 11:38, Achim Gratz wrote:

[Sorry, thought I'd sent this, it was backgrounded!]

What are the distinctions between /dev/sd[a-c][a-z], /dev/sdd[a-z], and
/dev/sd[a-z] appearing in parts of devices.cc?

s[6] == 'd'?

Better:

>   if (len > 7 && len < 12 && s[7] == 'd'
-   if (len > 7 && len < 12 && s[7] == 'd'
+   if (DP_LEN < len && len <= DP_LEN + 4 && 'd' == s[DP_LEN - 1]
>       /* Generic check for /dev/sd[a-z] prefix */
>       && strncmp (s, DISK_PREFIX, DP_LEN) == 0
>       && s[DP_LEN] >= 'a' && s[DP_LEN] <= 'z')

There are 127 each cons,nst,pty,ptym,st,ttyS entries allocated for potential
devices, which will not exist on most systems.

Note that GPT supports 128 partitions per device.

Are there systems using more than 32 of any supported device?

Are there documented Windows I/O device addressing limits?

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Cygwin: Provide more COM devices

Achim Gratz
Brian Inglis writes:
> On 2019-12-14 11:38, Achim Gratz wrote:
>
> [Sorry, thought I'd sent this, it was backgrounded!]
>
> What are the distinctions between /dev/sd[a-c][a-z], /dev/sdd[a-z], and
> /dev/sd[a-z] appearing in parts of devices.cc?

/dev/sd is the base name for disks, letters denote distinct units (a..dx
for a total of 128 units) and numbers the partitions (starting from 1,
with no number addressing the whole device), just like Linux.

The first 16 partitions of each drive have a fixed device major number
(out of 8) and mangle the drive / partition into the lower nibbles of
the minor.  Any drive with higher partition numbers gets mapped into 25
higher device numbers where the bits for the unit number spread across
major/minor and the remaining 48 partitions make up the lower part of
the minor.  I'd rather had kept the original numbering scheme and packed
each set of 16 extra partitions into one more major number for a total
of 24 extra, but that's what we have now.

> There are 127 each cons,nst,pty,ptym,st,ttyS entries allocated for potential
> devices, which will not exist on most systems.

You'll proably won't find a system with so many tapes, not.  But the way
Windows deals with USB devices means that you can easily have several
dozen of (virtual) COM ports, since it creates a distinct number for
each device / USB port combination you've ever used.  The limit is
probably even higher than the 128 ports Cygwin tries to support.

> Note that GPT supports 128 partitions per device.

But Cygwin only supports 64.

> Are there systems using more than 32 of any supported device?

I have systems that are way past COM64 and I seem to remember having
seen one with a COM port past 127.

> Are there documented Windows I/O device addressing limits?

You could have 256 since Win98 (not for DOS applications, though), but
that IIRC was always a limitation of the control panel, not the
underlying platform.  Not sure if Win10 changed something in that
regard, but probably not.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada